Search This Blog

Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Showing posts with label API Keys. Show all posts

Railway Tells 4.8 Million Users to Rotate Secrets After Possible Breach of Environment Variables







Railway, the cloud platform used by developers to deploy and run applications, APIs, and databases, has issued an urgent warning to its roughly 4.8 million users: rotate every secret stored on the platform right now. The company detected suspicious activity involving the systems that hold customer environment variables and says an unauthorized party may have accessed the encrypted files, and in some cases, obtained their decrypted contents.

The company published a security disclosure on Wednesday, October 21, describing the intrusion as affecting systems that store customer environment variables. Those files are where developers keep the sensitive strings that power their deployments: API keys for third-party services, database connection strings, private registry credentials, and authentication tokens. Railway paused all deployments on the platform immediately after the detection, bringing down builds for its entire user base while the investigation got underway.

"We strongly recommend that you immediately roll all environment variables, including any API keys."
[Railway, Security Disclosure — October 21, 2026]

By October 22, builds had been restored for Pro and Enterprise workspace customers, though Hobby, Free, and Trial tiers remained offline, with Railway saying it planned to restore them in that order. A follow-up post published October 23 clarified that any code commits pushed during the deployment freeze had not been deployed, meaning developers would need to manually redeploy their most recent commits once access was restored, and also reconnect GitHub integrations and recreate CLI and CI credentials that were issued during that window.

Railway says it believes the incident is part of a coordinated series of attacks specifically targeting cloud platforms that run AI inference workloads. The company stated it had directly notified upstream AI inference providers and asked them to revoke all keys as a precaution - a step that suggests the attackers were harvesting credentials to gain free access to AI model APIs, rather than pursuing user data for conventional financial fraud.

That theory fits a pattern that emerged just the week before on a competing platform. Zeabur, another cloud deployment service, disclosed on October 15 that an attacker had used leaked internal credentials to access its shared cluster infrastructure between October 14 and 15. The Zeabur post-mortem detailed how the intruder moved through the environment with unusual speed, running commands inside 865 user database containers and reading the environment variables and secrets of services across nine regions. Investigators noted the attacker specifically searched the platform database for AI service API keys, attempting to call Amazon Bedrock using Zeabur's own AWS credentials. A separate OpenAI key belonging to a Zeabur user appeared to have been used for over a thousand image generation requests in the hours after the breach. Zeabur attributed the root cause to long-lived admin credentials stored in plaintext and reachable over the public internet.

What Railway Users Should Do Now
  • Rotate all environment variables stored on Railway, including API keys for every third-party service.
  • Rotate private container registry credentials.
  • Review service logs for any unusual or unauthorized activity since October 21.
  • After builds resume, redeploy the latest commit manually and recreate CLI and CI credentials issued during the outage window.
  • Reconnect GitHub integrations if they were created after the freeze began.
Railway has not disclosed how many accounts are confirmed affected, saying only that initial analysis suggests the exposure is limited to a subset of its user base. The company says it will contact confirmed affected customers directly by email once the investigation identifies them. The platform hosts more than 16 million services, which means even a small percentage of users represents a substantial number of potentially compromised deployments.

For developers whose work depends on Railway, the incident is a reminder that secrets stored with a third-party platform inherit that platform's threat surface. Security practitioners have long recommended treating any externally stored credential as potentially compromised following an incident involving its host, regardless of whether that specific account appears in confirmed breach data. Railway's recommendation to rotate everything, not just keys flagged as compromised - follows that same logic. The cost of rotating a key is low; the cost of leaving a live key in an attacker's hands is not.

Railway said it will publish further details about the incident as the investigation continues and updates are being posted to its status page under incident reference QH8L8B3E.


OVHcloud CLI Packages on GitHub Were Replaced With Secret-Stealing Malware

 



Attackers replaced the binary releases of OVHcloud's open-source CLI tool on GitHub with malicious builds designed to harvest secrets from developer machines, the company confirmed this week. The incident, which affected versions v0.11.0 through v0.15.0, went live on October 19 and was only caught after a customer raised an alarm about a suspicious release.

The malicious files were live for roughly 94 minutes. A customer's CI pipeline, which had a pinned SHA-256 checksum for the v0.15.0 Linux binary, failed when the hash no longer matched, and the customer opened issue #300 on the public GitHub repository. OVHcloud pulled the replaced assets at 14:21 UTC and shipped a clean replacement, v0.16.0, three hours later.


A Compromised Account, Months in the Making

The attack traced back to a single GitHub account: `HassenBF`, belonging to a legitimate OVHcloud contributor who had write access to the release repository. According to the security research group OpenSourceMalware, the account was compromised roughly seven months before the attack, with evidence pointing to early March 2026.

On March 5 and 6, four personal repositories on the account were force-pushed within a scripted window. Three of those rewrites embedded a `preinstall.js` loader file containing a payload hidden inside invisible Unicode variation-selector characters. A fourth repository inlined the same decoder into a React source file. The push cadence for the first three repositories was 42 seconds, which OpenSourceMalware interpreted as automated rather than manual activity.

After that, the account went quiet on the CLI project. It continued contributing to `ovh/ovhcloud-docs` through May to September 2026, with several pull requests merged normally. That cover of normalcy made the account hard to flag.


How the Malicious Binaries Were Built

The attacker did not touch OVHcloud's CI/CD pipeline. Instead, they built the infected packages locally and uploaded them directly using the GitHub Releases API, replacing the macOS (Intel and ARM), Linux (x86_64 and ARM64), and Windows x86-64 binaries across five versions. The i386, Windows ARM64, and WASM builds were left alone, which OpenSourceMalware read as deliberate targeting of developer and operations workstations.

Critically, the attacker also replaced the `checksums.txt` file last, so the new hashes matched the malicious binaries. Anyone who verified the checksum would still get a false sense of security.

OVHcloud CEO Octave Klaba confirmed that GitHub's release immutability setting had been turned off on the repository, which is what allowed an account with write access to silently overwrite already-published releases without triggering any CI checks. Since the incident, OVHcloud has re-enabled that setting. The v0.16.0 release is now marked immutable, meaning its files cannot be replaced.

A forensic check of the malicious binary using `go version -m` revealed it was built from a git checkout with uncommitted changes (`vcs.modified=true`), a dead giveaway that it came from a local workstation build rather than the official GoReleaser pipeline.


The Payload: A Solana Dead Drop and GlassWorm Fingerprints

OpenSourceMalware dug into the `preinstall.js` file loaded into the compromised account's repositories back in March. The loader uses a two-stage design. The first stage AES-256-CBC decrypts a hex blob, and the resulting second-stage script checks whether the victim machine appears to be based in Russia by testing language and timezone settings; if it is, the script exits after 10 seconds.

Otherwise, it contacts public Solana RPC endpoints, queries transactions from a specific wallet address, and reads a JSON memo embedded in the blockchain. That memo carries a base64-encoded URL pointing to the next-stage payload. This "dead drop" technique lets the attacker swap out the payload URL anytime without touching any code repository.

The Solana wallet in question, `BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC`, appears in public indicator lists for GlassWorm, a threat actor that has been running campaigns since late 2025 targeting VS Code, OpenVSX, GitHub, and npm. OpenSourceMalware attributes this attack to GlassWorm with moderate confidence.


Who Is Affected and What to Do

Any developer or CI pipeline that downloaded or ran the CLI through `install.sh`, the Homebrew cask, or a direct GitHub release between 12:47 and 14:21 UTC on October 19 may have been exposed. Klaba said the malware's goal was to collect secrets sitting on disk, and while he described the binary as low quality, he warned it was still capable of doing real damage.

Affected users should update to v0.16.0 or roll back to v0.10.0 immediately, but updating the tool alone is not enough. Any machine that ran a compromised version should be treated as having all its readable secrets exposed. That means rotating OVHcloud API keys, cloud credentials, SSH keys, Kubernetes configs, package registry tokens, and anything stored in `.env` files, from a separate, clean machine. Users on macOS should also check for an `~/init.json` file in the home directory, which the second-stage script writes as a throttle marker.

OVHcloud has said a full post-mortem is coming. Key questions remain open: how the developer account credentials were first stolen, whether the same actor maintained access for the entire seven months, and exactly what the final payload did before OVHcloud deleted the files.



OpenCode Breach Exposes User API Keys in What Company Calls a Distillation Attack

 



An intruder broke into a legacy system at OpenCode late on October 16, gaining access to third-party AI provider API keys that users had stored inside OpenCode Console, the company's optional hosted service. The open-source coding platform disclosed the incident on October 17 and said 1.4% of its Console users were affected, all of whom had linked at least one external AI provider to their account.

OpenCode connected the breach to what it described as "a large-scale distillation attack," a method where someone collects outputs from frontier AI models to train a separate, competing model. Rather than building costly infrastructure or licensing training data, attackers use someone else's API access to query high-end models at scale, then feed those responses into their own system. The stolen asset in this case was not personal data but model access, specifically the ability to run queries against Claude, GPT-4, and Gemini on someone else's tab.


What Got Taken and What Did Not

OpenCode co-founder Dax Raad drew a line between accounts that stored keys in Console and those that used the local CLI or desktop app. Keys saved locally sit inside a SQLite database on the user's own machine and, as Raad noted, "never come to us." Those were not touched. Only keys that users explicitly uploaded to Console, which OpenCode stores server-side to route requests through its gateway, were within reach of the compromised system.

OpenCode has not specified what the legacy system was, how long the attacker had access, or how many users 1.4% translates to in real numbers. As of October 18, Raad said the company's systems had been under sustained pressure, with attackers attempting to get in "non stop" for 48 hours.


Users Report Charges Running Into Hundreds of Dollars

Reports on X and Reddit painted a more concrete picture of the damage. One user, Colin Parsons, said his accounts had been charged $281 on OpenAI and $168 on Anthropic. Another, Preston Zeller, reported a bill of $1,700. A Reddit thread gathered additional accounts, including roughly $400 in Anthropic usage and around 200 euros in Google Cloud charges that prompted Google to suspend the associated project.

OpenCode has not confirmed these figures as part of its own findings, and it has not addressed whether affected users will be reimbursed. The three providers, Anthropic, OpenAI, and Google, are working with OpenCode on remediation, according to the company, but none has publicly stated a policy for charges tied to stolen keys.

The mechanics of the situation make quick action important. An API key works for whoever holds it. Removing the key from inside OpenCode Console does nothing if the attacker already copied it. Console's built-in spend limits also cannot cap usage that happens outside OpenCode's own gateway, which means a copied key used directly against a provider's API bypasses those guardrails entirely.


The Distillation Attack Context

The technique OpenCode referenced is not new, and its scale in recent months has drawn attention from the companies whose models are being targeted. In February 2026, Anthropic flagged industrial-scale distillation activity, naming specific actors it said had extracted outputs from its models to train cheaper alternatives. Separately, U.S. officials noted that Chinese AI companies had pulled billions of tokens from frontier models through similar methods, a practice that lets firms skip large portions of the compute and research costs normally required to reach competitive performance levels.

What makes the OpenCode breach notable in this context is the method. Rather than scraping public interfaces or using their own accounts in violation of terms of service, the attackers here appear to have acquired legitimate credentials through a third-party breach, letting them operate under real user accounts with established billing relationships. That separation from direct account creation makes automated detection harder.


What Affected Users Should Do Now

OpenCode has advised affected users to rotate their keys immediately, but the precise steps matter. Rotating a key inside OpenCode Console alone is not sufficient. Users need to revoke the key from inside each provider's dashboard, where the credential is actually authenticated, then generate a new one and update every application or script that referenced the old key. Reviewing billing history going back to at least October 16 is also advisable, as any charges from queries the user did not make would show up in the provider's usage logs, not only inside OpenCode.

Security researchers have used the incident to argue against concentrating multiple provider keys inside a single third-party tool. Storing separate keys for separate platforms limits what any single breach can reach, and using keys with restricted permissions or lower spending thresholds reduces the potential damage if one is taken.

OpenCode says the investigation is ongoing.



GhostAction Returns: 772 GitHub Repos Hit as Supply Chain Campaign Picks Back Up

 



A GitHub Actions credential-theft campaign that researchers first flagged a year ago has returned with a fresh wave of attacks, hitting 772 public repositories between August 31 and September 30, 2026, and going after more than 2,500 developer secrets in the process.

The campaign, named GhostAction, was first reported in September 2025 after attackers compromised 817 public repositories across 327 GitHub user accounts and walked off with at least 3,325 secrets. It relied on injecting a malicious GitHub Actions workflow into victim repositories using what appeared to be stolen developer credentials. The 2026 wave uses the exact same method.

The attack injects a workflow file named `github_actions_security.yml` with the commit message "Add Github Actions Security workflow." Instead of dumping an entire environment, the attacker hardcodes into the workflow the specific secret names it already found referenced in the target's legitimate workflows, then sends those values in a single HTTP POST request to an attacker-controlled server.

The only meaningful change from 2025 is the exfiltration destination. This wave routes stolen data over plain HTTP to a bare IP address, `193.32.204.199`, replacing the named domains used previously. On September 7, a second variant appeared across seven repositories under the filename `security-check.yml`, posting secrets to a dedicated API endpoint on the same server with a unique identifier per injection. The tracking mechanism suggests the attacker now runs a backend that logs exactly which repository each stolen secret came from.


Three Bursts, 2,577 Targets

The injections rolled out in clusters. On August 31, 143 repositories were hit. Between September 2 and 5, roughly 400 more were targeted, with a single-day peak of 294 on September 5. On September 15, another 103 repositories were injected, with smaller activity continuing through the rest of the month.

Across all 772 repositories, the workflows targeted 2,577 secrets. SSH private keys and deployment server credentials were the most sought-after, appearing in 446 cases. Azure credentials followed at 218, with one organization alone exposing an Azure personal access token and an SSH key across 92 repositories. Container registry credentials for DockerHub and GHCR appeared 142 times; database credentials, 112; AWS access keys, 106; FTP credentials, 92; Google Cloud and Firebase credentials, 80; and GitHub tokens, 66. The list also included API keys for Telegram bots, Slack, Discord, npm, PyPI, and various AI providers.

GitHub's own approval mechanisms blunted much of the damage. Of 3,669 workflow runs tracked across 605 repositories, only 499 actually ran. A total of 336 completed successfully, exfiltrating 26 secrets from 13 repositories. Only 124 of the 772 affected repositories, roughly 16 percent, showed evidence of cleanup by October 5.


A Campaign That Never Stopped

Calling this a revival would be misleading. In 92 of the 2026 cases, the attacker did not add a new workflow at all. It modified one already sitting in the repository from an earlier injection, with the commit message "Update Github Actions Security workflow." Those updates simply pointed existing files at the new exfiltration IP, with the replaced endpoints including the original 2025 domains and a previously undocumented address, `170.39.218.2`.

The full timeline runs from September 2025 through the present: roughly 900 repositories in the initial wave, quieter activity across late 2025 and early 2026 under two different endpoints, then the August and September 2026 surge of 772.


A Cryptominer Hidden in DevOpsGPT

The new wave also produced an unexpected finding. A day and a half before the first August 31 injections, a commit labeled "fix(subtask): update the OpenAI version" was pushed to `kuafuai/DevOpsGPT`, an open-source project with roughly 6,000 stars. The commit embedded an XMRig 6.21.0 Monero miner into the project's Docker image, disguised as a routine worker process and set to run on a 45-second restart loop. The mining configuration was XOR-encrypted with the key `devops2024`, and the wallet pointed to `pool.supportxmr.com`.

The same compromised account was then used on September 15 to push the GhostAction workflow to four DevOpsGPT repositories. Whether the miner and the credential-theft campaign share the same operators remains unclear. The miner commit used a forged author email never seen on that account before, was crafted specifically for that project, and left no trace in any other repository, while GhostAction's payloads are generic and hit hundreds of repos within hours.


One Compromised Account, Multiple Attackers

Cross-referencing GhostAction victims against other malicious GitHub activity turned up 13 victim repositories that had also been exploited for cryptomining by at least four separate campaigns with distinct wallets, pools, and infrastructure. In some cases the miners arrived before the GhostAction workflow; in others they followed months later.

The most likely explanation is that the credentials GhostAction used were not exclusive to its operators. Stolen developer tokens circulate through infostealer logs and credential markets, where multiple actors can buy and reuse the same access independently.

That creates a specific gap in the standard remediation advice. Rotating the secrets stolen through the malicious workflow is necessary, but it is not enough. The underlying GitHub credential that allowed the injection in the first place also needs to be found and revoked, or whoever holds that token next will use it.

The campaign continued into October. On October 8, a new burst hit 346 repositories in two automated sweeps lasting only minutes. Two compromised maintainer accounts pushed the workflow to every repository they could write to, including kitao/pyxel, a Python retro game engine with over 18,400 stars, and uber/athenadriver. The exfiltration endpoint remained `193.32.204.199`. Unlike most of the September wave, which was blocked pending approval, these runs executed and exfiltration was confirmed. This variant also goes further than its predecessor: rather than targeting only named GitHub Actions secrets, it combs the full git commit history for cloud credentials, including AWS keys, GitHub and GitLab tokens, and API keys for services like OpenAI and Anthropic.


AgentCorruption Exposes Security Risks in Amazon Bedrock AgentCore

 

A single prompt could have led to the exposure of conversations, source code, stored memories and cloud credentials across multiple AI agents in the same AWS account and region, according to Zenity Labs researchers. The so-called AgentCorruption attack chain targeted Amazon Bedrock AgentCore, which is AWS's managed service for building and running AI agents. 

The researchers' proof-of-concept involved an agent with a web-request tool that was prompted to call the local metadata endpoint at 169.254.169.254, which is where AWS workloads get temporary AWS credentials. Since the request came from inside the agent's Firecracker microVM, it returned credentials for the agent's execution role. 

This created a server-side request forgery (SSRF) vulnerability that was triggered by a prompt injection. "Exploitation didn't require a vulnerability in the chat interface; it required only that the agent have a tool to make the request and that the tool be permitted to call the metadata service," the researchers said. Zenity discovered that the broad permissions typically given to the default execution role allowed them to find agents, obtain container images, invoke other agents and access session events. 

They also discovered permissions that could be used to access conversations and implant false memories that would affect the agent's future responses. The researchers added that the latter capability could be used to implant "instructions" that would cause the agent to take specific actions. In addition, they found that these same permissions could be used to access API keys and secrets stored in AWS Secrets Manager, which could lead to lateral movement to other services and data. 

According to Zenity, metadata access was reported to AWS on Dec. 25, 2025, and excessive permissions in the execution role were reported on Jan. 12, 2026. AWS started the migration to Instance Metadata Service Version 2 in February 2026, and then made it mandatory. On Sept. 29, 2026, Zenity confirmed that AWS had removed the permissions that could be used to invoke other agents, chat with them or access the Secrets Manager. The researchers stated that the problems they reported had been addressed. 

AWS pushed back against the suggestion that this was a vulnerability, noting that it is normal for an agent to have access to its own execution role credentials via the metadata service. In addition, the company stated that cross-account access to agents is not possible without the appropriate permissions on the execution role and resources. 

Security teams should create their own IAM roles with limited permissions, block all outbound network connectivity except what is necessary, isolate agents that are accessible over the public internet and monitor logs in CloudTrail and CloudWatch for anything unusual, the researchers recommended. They also suggested that organizations ensure that the AgentCore Gateway cannot be bypassed to access agents directly. 

An AI agent's access to tools and permissions in the cloud can create security issues if not properly restricted, and this discovery shows why companies need to carefully control and monitor such access before actually launching an agent into production.

Half a Million GitHub Credentials Are Still Active, Most Have Been Sitting in the Open for Years





Researchers at Truffle Security tested 543,699 API keys, database passwords, and access tokens found in public GitHub repositories last July. Every single one authenticated. The median credential had been sitting in publicly readable code for 784 days.

The findings come from a scan of The Stack v3, a 224-million-repository snapshot of public GitHub code assembled to train large language models. The crawl closed on August 7, 2025. Eleven months later, when Truffle Security ran live verification against each issuing provider, more than half a million credentials still worked. That number is more than double the 221,303 live credentials the company found when it ran a similar scan against 7.6 petabytes of Hugging Face training data earlier this year.

The oldest credential in the dataset was last touched on June 13, 2009. It lives inside an Erlang web server configuration file, and it was still valid 16.1 years after it was committed. Behind it: an FTP login inside a GPS logger's C source code from September 2009, replicated across 62 repositories, and an AWS key tucked inside a Rails S3 config from November of that same year. Truffle Security declined to name the repositories because the credentials in them still work.


A Protection That Only Faces Forward

GitHub has progressively tightened its defenses around exposed credentials. The platform made secret scanning alerts free for all public repositories in February 2023. Push protection, which blocks a commit before it reaches the remote branch if it carries a recognised secret, became generally available in May 2023 and was switched on by default for all public repositories on February 29, 2024.

GitHub's secret scanning covers more than 200 token types and patterns from over 180 service providers. The rollout had a measurable effect on new leaks. Among credential shapes the system recognises and blocks, Truffle Security found a 53 percent drop in the rate of fresh exposures across the twelve months following the default rollout, compared to the twelve months before it. Slack tokens fell 64 percent, GitHub's own tokens and AWS access keys each fell 59 percent.

But push protection has no mechanism to reach the credentials already there. Of the 543,699 live credentials, 199,843 landed after push protection became the default in February 2024. Developers either bypassed the block or committed credential types the system does not recognise.

That second category is the larger problem. Truffle Security found that 51.8 percent of every live credential in the dataset is a shape that a default-configured public repository will accept without objection. Database connection strings, private keys, and Google API keys all fall outside the default block list. Push protection focuses on specific, highly identifiable secrets and misses generic ones. Connection strings and private keys are classified as generic patterns, and blocking them requires an organisation to go into settings and explicitly opt in.


The Gemini Problem

The Google API key situation illustrates the limits of pattern-based blocking in particularly sharp terms. The 33,343 live Google API keys in Truffle Security's dataset include 31,374 that authenticate specifically to Gemini, Google's AI model platform. Their median leak date is February 2025, meaning the entire population is younger than the push protection rollout.

Google API keys carry the prefix `AIzaSy` whether they were created for Google Maps, Firebase, or Gemini. GitHub's pattern list recognises the prefix but marks it as not push-protected, because a Maps key sitting in client-side JavaScript is not a secret by design. Google's own approach to API keys was historically built around the assumption that these keys would live in client-side code, exposed to anyone who opened a browser's developer tools. The problem is that Gemini runs on the same key format, turning what developers were trained to treat as a non-sensitive identifier into a billable AI credential. One pattern cannot distinguish between the two uses, so nothing gets blocked, and the keys that matter arrive alongside the keys that do not.


Revocation is the Deciding Variable

The most instructive comparison in the data is between providers that automatically revoke leaked tokens and those that do not.

npm committed 101,886 tokens to public code. One remains live. GitHub committed 73,048 tokens; 260 survived. Hugging Face committed 30,437; 15 are still valid. Each of these platforms runs an automated pipeline that kills a token the moment it is detected in public code.

The contrast with database credentials is stark. Of 12,985 Postgres connection strings in the dataset, 11,465 are still live, an 88 percent survival rate. MySQL connection strings survive at 75 percent. MongoDB, where the detector only reports a URI it successfully connected to, returned all 51,067 live.

Push protection blocks secrets at the door. Automated revocation kills them wherever they are. The Truffle Security data shows that the second mechanism is the one that changes the outcome, and for the majority of credential types sitting in public repositories right now, no provider is running it.

The practical guidance from the researchers: treat any committed credential as compromised regardless of whether anything flagged it, scan your own repository history rather than assuming the push-time block was sufficient, and favour credentials that expire automatically. Most of what Truffle Security found would have been harmless long ago if it had ever been given a finite lifetime.


ClickUp API Key Exposure Leaves Corporate and Government Email Data Public for Over a Year

 

A previously unnoticed weakness in ClickUp’s web infrastructure sat undetected - exposing private data due to an embedded API key left visible on its public site. For over twelve months, access to internal records remained possible because safeguards were missing at a basic level. Emails tied to businesses and official agencies could be pulled by outside parties; no login required. This gap emerged not from complex hacking but from routine coding oversights ignored during deployment. Hidden credentials like these often escape review until examined closely. Months passed before scrutiny revealed what should have been caught earlier. Security gaps of this kind stem less from advanced threats and more from everyday lapses repeated across teams. 

Open talk about the problem began when security analyst Impulsive shared findings showing the leaked credential sat inside a JavaScript file served by ClickUp's site, even before login steps occurred. Since code running in browsers can always be seen, grabbing the API key took little effort and allowed contact with internal servers. Without needing any special access, one basic query allegedly pulled close to a thousand emails plus vast numbers of hidden development settings from the system. The study showed that 959 employee email addresses were part of the leaked data, tied to staff in large companies and public institutions spanning various locations. 

About 3,165 feature flags also turned up in the exposure - visible without restriction. Hidden inside what looks like routine code, these flags might expose how teams test software, plan releases, roll out new tools, or shape future updates. Because of that, malicious actors might mine them to craft deceptive emails, manipulate individuals through tailored messages, or collect insights on rivals’ progress. Surprisingly useful intel often hides where it seems least likely. Early in 2025, news of the exposure surfaced - yet by April 2026, it still hadn’t been fixed, stretching out the time hackers could act. Because access stayed open so long, experts say attackers gained more chances to try breaking in using stolen login details, fake identities, or personalized emails targeting workers linked to the affected websites. 

What happened shows a wider issue for groups depending on cloud-based services. Though easy to avoid, fixed login details remain common in today’s coding practices. When secret access tokens appear in open-source repositories, bots usually find them fast - sometimes in under sixty seconds. Even low-level access codes can lead to large data leaks if internal systems lack strong verification rules. Rotating API keys often helps lower exposure over time. Client-side apps without embedded secrets tend to withstand attacks better. Strict limits on backend access form another layer of defense. 

Protection against phishing gains strength when using tools like DMARC, SPF, or DKIM. Unusual logins catch attention faster with constant tracking. Exposed domains become visible through active threat data streams. Security improves not by one fix alone, but steady adjustments across systems. A quiet mistake lingered unseen within ClickUp's system, revealing data widely before detection. When operations move into shared online environments, oversight gaps often emerge - making careful monitoring essential. Security lapses like this highlight growing pressure on organizations to act earlier, respond smarter, stay alert longer.

Google API Keys Expose Gemini AI Data via Leaked Credentials

 

Google API keys, once considered harmless when embedded in public websites for services like Maps or YouTube, have turned into a serious security risk following the integration of Google's Gemini AI assistant. Security researchers at Truffle Security uncovered this issue, revealing that nearly 3,000 live API keys—prefixed with "AIza"—are exposed in client-side JavaScript code across popular sites.

Truffle Security's scan of the November 2025 Common Crawl dataset, which captures snapshots of major websites, identified 2,863 active keys from diverse sectors including finance, security firms, and even Google's own infrastructure. These keys, deployed sometimes years ago (one traced back to February 2023), were originally safe as mere billing identifiers but gained unauthorized access to Gemini endpoints without developers' knowledge.Attackers can simply copy a key from page source, authenticate to Gemini, and extract sensitive data like uploaded files, cached contexts, or datasets via simple prompts.

The danger extends beyond data theft to massive financial abuse, as Gemini API calls consume tokens that rack up charges—potentially thousands of dollars daily per compromised account, depending on the model and context window. Truffle Security demonstrated this by querying the /models endpoint with exposed keys, confirming access to private Gemini features. One reported case highlighted an $82,314 bill from a stolen key, underscoring the real-world impact.

Google acknowledged the flaw as "single-service privilege escalation" after Truffle's disclosure on November 21, 2025, and implemented fixes by January 2026, including blocking leaked keys from Gemini access, defaulting new AI Studio keys to Gemini-only scope, and sending proactive leak notifications. Despite these measures, the "retroactive privilege expansion" caught many off-guard, as enabling Gemini in projects silently empowered old keys.

Developers must immediately audit Google Cloud projects for Gemini API enablement, rotate all exposed keys, and restrict scopes to essentials—avoiding the default "unrestricted" setting. Tools like TruffleHog can scan code repositories for leaks, while regular monitoring prevents future exposures in an era where AI services amplify API risks. This incident highlights the need for vigilance as cloud features evolve.

Publicly Exposed Google Cloud API Keys Gain Unintended Access to Gemini Services

 










A recent security analysis has revealed that thousands of Google Cloud API keys available on the public internet could be misused to interact with Google’s Gemini artificial intelligence platform, creating both data exposure and financial risks.

Google Cloud API keys, often recognizable by the prefix “AIza,” are typically used to connect websites and applications to Google services and to track usage for billing. They are not meant to function as high-level authentication credentials. However, researchers from Truffle Security discovered that these keys can be leveraged to access Gemini-related endpoints once the Generative Language API is enabled within a Google Cloud project.

During their investigation, the firm identified nearly 3,000 active API keys embedded directly in publicly accessible client-side code, including JavaScript used to power website features such as maps and other Google integrations. According to security researcher Joe Leon, possession of a valid key may allow an attacker to retrieve stored files, read cached content, and generate large volumes of AI-driven requests that would be billed to the project owner. He further noted that these keys can now authenticate to Gemini services, even though they were not originally designed for that purpose.

The root of the problem lies in how permissions are applied when the Gemini API is activated. If a project owner enables the Generative Language API, all existing API keys tied to that project may automatically inherit access to Gemini endpoints. This includes keys that were previously embedded in publicly visible website code. Critically, there is no automatic alert notifying users that older keys have gained expanded capabilities.

As a result, attackers who routinely scan websites for exposed credentials could capture these keys and use them to access endpoints such as file storage or cached content interfaces. They could also submit repeated Gemini API requests, potentially generating substantial usage charges for victims through quota abuse.

The researchers also observed that when developers create a new API key within Google Cloud, the default configuration is set to “Unrestricted.” This means the key can interact with every enabled API within the same project, including Gemini, unless specific limitations are manually applied. In total, Truffle Security reported identifying 2,863 active keys accessible online, including one associated with a Google-related website.

Separately, Quokka published findings from a large-scale scan of 250,000 Android applications, uncovering more than 35,000 unique Google API keys embedded in mobile software. The company warned that beyond financial abuse through automated AI requests, organizations must consider broader implications. AI-enabled endpoints can interact with prompts, generated outputs, and integrated cloud services in ways that amplify the consequences of a compromised key.

Even in cases where direct customer records are not exposed, the combination of AI inference access, consumption of service quotas, and potential connectivity to other Google Cloud resources creates a substantially different risk profile than developers may have anticipated when treating API keys as simple billing identifiers.

Although the behavior was initially described as functioning as designed, Google later confirmed it had collaborated with researchers to mitigate the issue. A company spokesperson stated that measures have been implemented to detect and block leaked API keys attempting to access Gemini services. There is currently no confirmed evidence that the weakness has been exploited at scale. However, a recent online post described an incident in which a reportedly stolen API key generated over $82,000 in charges within a two-day period, compared to the account’s typical monthly expenditure of approximately $180.

The situation remains under review, and further updates are expected if additional details surface.

Security experts recommend that Google Cloud users audit their projects to determine whether AI-related APIs are enabled. If such services are active and associated API keys are publicly accessible through website code or open repositories, those keys should be rotated immediately. Researchers advise prioritizing older keys, as they are more likely to have been deployed publicly under earlier guidance suggesting limited risk.

Industry analysts emphasize that API security must be continuous. Changes in how APIs operate or what data they can access may not constitute traditional software vulnerabilities, yet they can materially increase exposure. As artificial intelligence becomes more tightly integrated with cloud services, organizations must move beyond periodic testing and instead monitor behavior, detect anomalies, and actively block suspicious activity to reduce evolving risk.

How Poorly Secured Endpoints Are Expanding Risk in LLM Infrastructure

 


As organizations build and host their own Large Language Models, they also create a network of supporting services and APIs to keep those systems running. The growing danger does not usually originate from the model’s intelligence itself, but from the technical framework that delivers, connects, and automates it. Every new interface added to support an LLM expands the number of possible entry points into the system. During rapid rollouts, these interfaces are often trusted automatically and reviewed later, if at all.

When these access points are given excessive permissions or rely on long-lasting credentials, they can open doors far wider than intended. A single poorly secured endpoint can provide access to internal systems, service identities, and sensitive data tied to LLM operations. For that reason, managing privileges at the endpoint level is becoming a central security requirement.

In practical terms, an endpoint is any digital doorway that allows a user, application, or service to communicate with a model. This includes APIs that receive prompts and return generated responses, administrative panels used to update or configure models, monitoring dashboards, and integration points that allow the model to interact with databases or external tools. Together, these interfaces determine how deeply the LLM is embedded within the broader technology ecosystem.

A major issue is that many of these interfaces are designed for experimentation or early deployment phases. They prioritize speed and functionality over hardened security controls. Over time, temporary testing configurations remain active, monitoring weakens, and permissions accumulate. In many deployments, the endpoint effectively becomes the security perimeter. Its authentication methods, secret management practices, and assigned privileges ultimately decide how far an intruder could move.

Exposure rarely stems from a single catastrophic mistake. Instead, it develops gradually. Internal APIs may be made publicly reachable to simplify integration and left unprotected. Access tokens or API keys may be embedded in code and never rotated. Teams may assume that internal networks are inherently secure, overlooking the fact that VPN access, misconfigurations, or compromised accounts can bridge that boundary. Cloud settings, including improperly configured gateways or firewall rules, can also unintentionally expose services to the internet.

These risks are amplified in LLM ecosystems because models are typically connected to multiple internal systems. If an attacker compromises one endpoint, they may gain indirect access to databases, automation tools, and cloud resources that already trust the model’s credentials. Unlike traditional APIs with narrow functions, LLM interfaces often support broad, automated workflows. This enables lateral movement at scale.

Threat actors can exploit prompts to extract confidential information the model can access. They may also misuse tool integrations to modify internal resources or trigger privileged operations. Even limited access can be dangerous if attackers manipulate input data in ways that influence the model to perform harmful actions indirectly.

Non-human identities intensify this exposure. Service accounts, machine credentials, and API keys allow models to function continuously without human intervention. For convenience, these identities are often granted broad permissions and rarely audited. If an endpoint tied to such credentials is breached, the attacker inherits trusted system-level access. Problems such as scattered secrets across configuration files, long-lived static credentials, excessive permissions, and a growing number of unmanaged service accounts increase both complexity and risk.

Mitigating these threats requires assuming that some endpoints will eventually be reached. Security strategies should focus on limiting impact. Access should follow strict least-privilege principles for both people and systems. Elevated rights should be granted only temporarily and revoked automatically. Sensitive sessions should be logged and reviewed. Credentials must be rotated regularly, and long-standing static secrets should be eliminated wherever possible.

Because LLM systems operate autonomously and at scale, traditional access models are no longer sufficient. Strong endpoint privilege governance, continuous verification, and reduced standing access are essential to protecting AI-driven infrastructure from escalating compromise.

Critical better-auth Flaw Enables API Key Account Takeover

 

A flaw in the better-auth authentication library could let attackers take over user accounts without logging in. The issue affects the API keys plugin and allows unauthenticated actors to generate privileged API keys for any user by abusing weak authorization logic. Researchers warn that successful exploitation grants full authenticated access as the targeted account, potentially exposing sensitive data or enabling broader application compromise, depending on the user’s privileges. 

The better-auth library records around 300,000 weekly downloads on npm, making the issue significant for applications that rely on API keys for automation and service-to-service communication. Unlike interactive logins, API keys often bypass multi-factor authentication and can remain valid for long periods. If misused, a single key can enable scripted access, backend manipulation, or large-scale impersonation of privileged users. 

Tracked as CVE-2025-61928, the vulnerability stems from flawed logic in the createApiKey and updateApiKey handlers. These functions decide whether authentication is required by checking for an active session and the presence of a userId in the request body. When no session exists but a userId is supplied, the system incorrectly skips authentication and builds user context directly from attacker-controlled input. This bypass avoids server-side validation meant to protect sensitive fields such as permissions and rate limits. 

In practical terms, an attacker can send a single request to the API key creation endpoint with a valid userId and receive a working key tied to that account. The same weakness allows unauthorized modification of existing keys. Because exploitation requires only knowledge or guessing of user identifiers, attack complexity is low. Once obtained, the API key allows attackers to bypass MFA and operate as the victim until the key is revoked. 

A patched version of better-auth has been released to fix the authorization checks. Organizations are advised to upgrade immediately, rotate potentially exposed API keys, review logs for suspicious unauthenticated requests, and tighten key governance through least-privilege permissions, expiration policies, and monitoring. 

The incident highlights broader risks tied to third-party authentication libraries. Authorization flaws in widely adopted components can silently undermine security controls, reinforcing the need for continuous validation, disciplined credential management, and zero-trust approaches across modern, API-driven environments.

Salesloft Integration Breach Exposes Salesforce Customer Data


 

A recent cyber incident has brought to light how one weak link in software integrations can expose sensitive business information. Salesloft, a sales automation platform, confirmed that attackers exploited its Drift chat integration with Salesforce to steal tokens that granted access to customer environments.

Between August 8 and August 18, 2025, threat actors obtained OAuth and refresh tokens connected to the Drift–Salesforce integration. These tokens work like digital keys, allowing connected apps to access Salesforce data without repeatedly asking for passwords. Once stolen, the tokens were used to log into Salesforce accounts and extract confidential data.

According to Salesloft, the attackers specifically searched for credentials such as Amazon Web Services (AWS) keys, Snowflake access tokens, and internal passwords. The company said the breach only impacted customers who used the Drift–Salesforce connection, while other integrations were unaffected. As a precaution, all tokens for this integration were revoked, forcing customers to reauthenticate before continuing use.

Google’s Threat Intelligence team, which is monitoring the attackers under the name UNC6395, reported that the group issued queries inside Salesforce to collect sensitive details hidden in support cases. These included login credentials, API keys, and cloud access tokens. Investigators noted that while the attackers tried to cover their tracks by deleting query jobs, the activity still appears in Salesforce logs.

To disguise their operations, the hackers used anonymizing tools like Tor and commercial hosting services. Google also identified user-agent strings and IP addresses linked to the attack, which organizations can use to check their logs for signs of compromise.

Security experts are urging affected administrators to rotate credentials immediately, review Salesforce logs for unusual queries, and search for leaked secrets by scanning for terms such as “AKIA” (used in AWS keys), “Snowflake,” “password,” or “secret.” They also recommend tightening access controls on third-party apps, limiting token permissions, and shortening session times to reduce future risk.

While some extortion groups have publicly claimed responsibility for the attack, Google stated there is no clear evidence tying them to this breach. The investigation is still ongoing, and attribution remains uncertain.

This incident underlines the broader risks of SaaS integrations. Connected apps are often given high levels of access to critical business platforms. If those credentials are compromised, attackers can bypass normal login protections and move deeper into company systems. As businesses continue relying on cloud applications, stronger governance of integrations and closer monitoring of token use are becoming essential.




Rise in Data-Stealing Malware Targeting Developers, Sonatype Warns

 

A recent report released on April 2 has uncovered a worrying rise in open-source malware aimed at developers. These attacks, described as “smash and grab” operations, are designed to swiftly exfiltrate sensitive data from development environments.

Brian Fox, co-founder and CTO of Sonatype, explained that developers are increasingly falling victim to deceptive software packages. Once installed, these packages execute malicious code to harvest confidential data such as API keys, session cookies, and database credentials—then transmit it externally.

“It’s over in a flash,” Fox said. “Many of the times, people don’t recognize that this was even an attack.”

Sonatype, a leader in software supply-chain security, revealed that 56% of malware identified in Q1 2025 focused on data exfiltration. These programs are tailored to extract sensitive information from compromised systems. This marks a sharp increase from Q4 2024, when only 26% of open-source threats had such capabilities. The company defines open-source malware as “malicious code intentionally crafted to target developers in order to infiltrate and exploit software supply chains.”

Fox emphasized that these attacks often begin with spear phishing tactics—posing as legitimate software packages on public repositories. Minor changes, such as replacing hyphens with underscores in filenames, can mislead even seasoned developers.

“The attackers fake the number of downloads. They fake the stars so it can look as legit as the original one, because there’s not enough awareness. [Developers] are not yet trained to be skeptical,” Fox told us.

These stolen data fragments—while small—can have massive consequences. API keys, hashed passwords, and cookie caches serve as backdoors for broader attacks.

“They’re breaking into the janitor’s closet, not to put in a bomb, but to grab his keychain, and then they’re going to come back at night with the keychain,” Fox said.

The 2025 report highlights early examples:

Compromised JavaScript packages on npm were found to steal environment variables, which typically contain API tokens, SSH credentials, and other sensitive information.

A fake npm extension embedded spyware that enabled complete remote access.

Malicious packages targeted cryptocurrency developers, deploying Windows trojans capable of keylogging and data exfiltration. These packages had over 1,900 downloads collectively.

A separate report published by Sonatype in November 2024 reported a 156% year-over-year surge in open-source malware. Since October 2023, over 512,847 malicious packages have been identified—including but not limited to data-exfiltrating malware.

HaveIBeenPwned Founder Compromised in Phishing Incident

 


The cybersecurity expert Troy Hunt, who founded the data breach notification platform Have I Been Pwned, recently revealed that he had been the victim of a phishing attack that was intended to compromise his subscriber list for the attacker to gain access to his data. Hunt explained the circumstances surrounding this incident in a detailed blog post, and provided screenshots of the deceptive email which enabled the attack to succeed.

In the fraudulent message, the author impersonated Mailchimp, a legitimate email marketing company, and embedded a hyperlink that was directed to a nearly identical, but fraudulent domain, which was a common phishing attack. It was very difficult to distinguish at a glance between the spoofed and authentic domains, which is why MailChimp-sso.com (now deactivated) is so closely similar. In Hunt's case, he acknowledged that he was severely fatigued at the time of the attack, which made it harder for him to act correctly. He also mentioned that he was experiencing jet lag at the time of the attack. 

In response to the email, he accidentally entered his credentials along with the one-time password, which was used for authentication. However, the fraudulent webpage did not proceed to the expected interface as he expected, signalling that the attack had been carried out. As a result of this incident, phishing scams represent a very prevalent risk, which underscores the importance of maintaining constant vigilance, even among cybersecurity professionals.

As soon as Troy Hunt discovered that he had been victimized by a phishing scam, he reset his password and reviewed his account activity immediately. However, since the phishing attack was highly automated, his credentials were already exfiltrated by the time he could respond. Although Hunt has extensive cybersecurity experience, this particular phishing attempt proved to be extremely successful. 

Hunt attributes the success to both his exhaustion after a long flight, as well as the sophistication of the email that was intended to fool others. According to him, the phish was "well-crafted" and was subtly manipulating psychological triggers. In the email, rather than utilizing overt threats or excessive urgency, it was suggested that he would not be able to send newsletters unless he took action. It was thus possible to send the email with just the right amount of apprehension to prompt action without creating suspicions. 

As a result, Hunt, the founder of the Have I Been Pwned platform, a platform that alerts people to compromised credentials, has taken steps to ensure that the information exposed in this incident will be incorporated into his platform in the future, which he hopes will lead to improved performance. A direct notification will be sent to individuals who have been affected by the breach, including both current subscribers and those who have already unsubscribed but are still impacted by the breach. 

Troy Hunt, a cybersecurity expert who runs a blog dedicated to cyber security and privacy, was targeted on March 25, 2018, by a phishing attack that compromised subscriber data from his blog. The attack originates from an email that impersonates Mailchimp, the platform he uses for sending out blog updates via email. According to the fraudulent message, his account had been suspended temporarily because of a spam complaint and he was required to login in order to resolve it.

The fake email made it look authentic by threatening disruption of service and creating a sense of urgency. Hunt was unable to distinguish this attack despite his extensive experience in identifying similar scams, as he was fatigued and jet lag affected his judgment in the process. In his attempt to log in with the email's link, he noticed an anomaly-his password manager did not automatically fill in his credentials. As a result, this could indicate that the website is fraudulent, but this is not a definitive indication, since legitimate services sometimes require a login from a different domain in some cases. 

As a result of the attack, approximately 16,000 email records were successfully exfiltrated, including those of active and unsubscribed readers alike. It is the result of Mailchimp's policy of retaining unsubscribed user information, a practice that is now being reviewed. There were emails, subscription statuses, IP addresses, location metadata and email addresses included in the compromised data, though the geolocation data did not pinpoint subscriber locations specifically. 

When the breach was discovered, immediate steps were taken to prevent further damage from occurring. It was determined that the attacker's API key would be revoked by Mailchimp, and the phishing website would be taken offline once the password was reset. Founder of Have I Been Pwned, a platform that tracks data breaches, Hunt has now added this incident to its database, making sure that affected users have been made aware of the incident. 

As phishing has become increasingly sophisticated over the years, it has moved beyond stereotypical poorly worded emails and implausible requests, moving into new levels of complexity. Cybercriminals today employ extremely sophisticated tactics that take advantage of human psychology, making it more and more difficult for consumers to distinguish between legitimate and fraudulent communications. The recent incident highlights the growing risks associated with targeted phishing attacks, as well as the importance of cybersecurity awareness and defense. 

Key Insights and Takeaways:

Psychological Manipulation and the Subtle Use of Urgency 

The majority of phishing emails are crafted to create a feeling of immediate panic, such as threats of account suspension or urgent payment requests, causing immediate panic within the target. However, modern attackers have honed their strategies, utilizing subtle psychological strategies to weaken the defences of their targets. As a matter of fact, in this case, the fraudulent email implied a very minor yet urgent issue: that the newsletter could not be sent. To manipulate the recipient into taking action, the email created just enough concern without raising suspicions, which led the recipient to respond to the email effectively. It is therefore imperative to recognize psychological manipulation in social engineering attacks, even for small requests that are relatively urgent, especially when it comes to logging into an account or updating one's credentials, to be viewed with suspicion. 

Password Manager Behavior as a Security Indicator 

In this attack, several red flags were pointing at Hunt's password manager's behaviour. Password managers are designed to recognize and auto-fill credentials only when they are used on legitimate websites. It should have been a warning sign in this case that the credentials of the user failed to automatically populate on the website, which could have indicated the website was fraudulent. By paying close attention to their password manager behaviour, users will be able to become more aware of security risks associated with their password manager. The site may be a spoofed one if the credentials are not automatically filled. Instead of entering the login details manually, users should double-check the source of the website and confirm it is authentic before proceeding with the transaction. 

The Limitations of One-Time Passwords (OTPs) in Phishing Attacks 

The multi-factor authentication (MFA) technique is widely considered to be one of the best security measures available, but it is not immune to phishing attacks. In this case, the attackers also requested Hunt to provide a password along with an OTP after he provided his username and password. Once he provided the password, the attackers gained access to his legitimate account immediately. 

A major weakness of OTP-based authentication is the inability to protect against real-time phishing attacks, where credentials are stolen and used instantly. The risk can be mitigated by requiring users to enter OTPs when they see sites that look suspicious or differ slightly from their usual login flow. Users are advised to be cautious when they are asked to enter OTP.

Passkeys as a Stronger, Phishing-Resistant Alternative There is no better way to authenticate a user than using passkeys, which are cryptographic credentials linked to the device of a user instead of traditional passwords. Passkeys are based on biometric authentication, for example, fingerprints, facial recognition, or even on-device authentication mechanisms. 

As passkeys are not associated with manually entering credentials, they have a much higher resistance to phishing attacks than traditional passwords. Passkeys work on the trust-based model, unlike passwords and OTPs, where they require physical access to the device registered for authentication. In contrast to traditional login methods, passkeys are a powerful alternative that can be used in place of traditional login methods and can serve as a valuable defence against phishing attempts as well. 

The Importance of Continuous Security Awareness 


Despite their expertise, even cybersecurity experts can be susceptible to sophisticated attacks, highlighting the importance of maintaining constant vigilance. The best way to enhance your security is to verify URLs carefully – Keep an eye out for slight misspellings or variations in URLs, as attackers are often able to create a lookalike URL by using security keys or passkeys. By using hardware-based authentication, such as YubiKeys, or passkeys, you can be assured that your information will be secure. If anyone receives a suspicious email asking for login credentials, security updates, or sensitive actions, be cautious and verify the message separately. 

Using Advanced Threat Protection – Organizations should take advantage of tools powered by artificial intelligence that are capable of detecting phishing attempts and blocking them in real-time. Educating Employees and Individuals – By attending regular cybersecurity training, you can become aware of the ever-evolving tactics used by phishing websites, minimizing the chances of human error. 

Although it is not possible to ensure complete protection against phishing attacks with just one security measure, adopting a multi-layered approach, a combination of awareness, technological safeguards, and behavioural vigilance, can greatly reduce your chances of becoming a victim of the attack. Despite being an experienced cybersecurity professional, even the most experienced individuals are not immune to social engineering techniques as demonstrated by the Troy Hunt incident. 

There was a significant contribution of fatigue and reduced attentiveness in this case, leading to a misjudgment that was essentially avoidable. It is known that social engineering can be extremely effective when it is employed in the right circumstances to reach the right people at the right time, resulting in a misjudgment that could have been avoided if it had been implemented correctly. The incident illustrates the way cybercriminals are using human weaknesses to achieve their objectives by exploiting human vulnerabilities. 

According to Aditi Gupta, a principal security consultant at Black Duck, attackers use a variety of tactics to manipulate unsuspecting victims, such as fear, urgency, and fatigue, to fool inexperienced people, reinforcing the theory that no one can escape sophisticated phishing schemes altogether. However, Hunt has been praised for being transparent in sharing his experience, which has served as a powerful tool for educating others about the risks associated with cybersecurity, despite the setbacks he has experienced. 

Despite admitting that he had made mistakes, he also expressed concern about Mailchimp’s security practices, especially the fact that the company did not offer two-factor authentication that is phishing resistant and kept intact for years to come. Cyber threats are not only mitigated through continuous vigilance, robust authentication mechanisms, and organizational responsibility, but also through continuous vigilance, robust authentication mechanisms, and organizational responsibility. 

The threat of social engineering attacks continues to increase and to remain protected from these attacks, it is imperative to strengthen security protocols, eliminate conventional authentication methods, and maintain cybersecurity awareness throughout the organization.

Thousands of iOS Apps Expose Sensitive Data Through Hardcoded Secrets, Researchers Warn

 

Cybersecurity researchers have uncovered alarming vulnerabilities in thousands of iOS applications, revealing that hardcoded secrets in their code have put users' sensitive information at risk.

A recent analysis by Cybernews examined over 156,000 iOS apps and detected more than 815,000 hardcoded secrets—some of which are highly sensitive and could potentially lead to security breaches or data leaks.

The term "secret" broadly refers to sensitive credentials like API keys, passwords, and encryption keys. These are often embedded directly into an app’s source code for convenience during development, but developers sometimes fail to remove them before release. According to Cybernews, the average iOS app exposes 5.2 secrets, and 71% of apps contain at least one leaked credential.

While some of these hardcoded secrets pose minimal risk, the report highlights serious threats. Researchers identified over 83,000 cloud storage endpoints, with 836 exposed without authentication, potentially leaking more than 400TB of data. Additionally, 51,000 Firebase endpoints were discovered, thousands of which were accessible to outsiders. Other exposed credentials include API keys for platforms like Fabric API, Live Branch, and MobApp Creator.

Among the most critical findings were 19 hardcoded Stripe secret keys, which directly control financial transactions. Cybernews researchers emphasized the severity of this issue, stating: “Stripe is widely used by e-commerce and even fintech companies to handle online payments.”

This vulnerability could allow cybercriminals to manipulate transactions or gain unauthorized access to payment infrastructure.

The findings challenge the common belief that iOS apps offer stronger security compared to other platforms.

“Many people believe that iOS apps are more secure and less likely to contain malware. However, our research shows that many apps in the ecosystem contain easily accessible hardcoded credentials. We followed the trail and found open databases with personal data and accessible infrastructure,” said Aras Nazarovas, a security researcher at Cybernews.

This study underscores the importance of secure coding practices and urges developers to adopt better security protocols to prevent data breaches and unauthorized access.


Revolutionizing Security: Passkeys by Google and Apple

Online security has grown to be of utmost importance in a digital environment that is always changing. Passkeys, a cutting-edge authentication system that is poised to transform how we protect our accounts, are being pushed for by Google and Apple, who are leading the effort.

Passkeys, also known as cryptographic keys, are a form of authentication that rely on public-key cryptography. Unlike traditional passwords, which can be vulnerable to hacking and phishing attacks, passkeys offer a more robust and secure method of verifying user identity. By generating a unique pair of keys – one public and one private – passkeys establish a highly secure connection between the user and the platform.

One of the key advantages of passkeys is that they eliminate the need for users to remember complex passwords or go through the hassle of resetting them. Instead, users can rely on their devices to generate and manage these cryptographic keys. This not only simplifies the login process but also reduces the risk of human error, a common factor in security breaches.

Google and Apple have been at the forefront of this innovation, integrating passkey technology into their platforms. Apple, for instance, has introduced the Passkeys API in iOS, making it easier for developers to implement this secure authentication method in their apps. This move signifies a significant shift towards a more secure and user-friendly digital landscape.

Moreover, passkeys can play a pivotal role in thwarting phishing attacks, which remain a prevalent threat in the online realm. Since passkeys are tied to specific devices, even if a user inadvertently falls victim to a phishing scam, the attacker would be unable to gain access without the physical device.

While passkeys offer a promising solution to enhance online security, it's important to acknowledge potential challenges. For instance, the technology may face initial resistance due to a learning curve associated with its implementation. Additionally, ensuring compatibility across various platforms and devices will be crucial to its widespread adoption.

Passkeys are a major advancement in digital authentication. Google and Apple are leading a push toward a more secure and frictionless internet experience by utilizing the power of public-key cryptography. Users might anticipate a time in the future when the laborious practice of managing passwords is a thing of the past as this technology continues to advance. Adopting passkeys is a step toward improved security as well as a step toward a more user-focused digital environment.

Reddit Blackout: Subreddits Protest New Pricing Policy

 

In a show of protest against Reddit's new pricing policy, thousands of subreddits are planning to go private for 48 hours starting on Monday. This move aims to bring attention to concerns about the platform's recent changes and their potential impact on the Reddit community.

The protest comes in response to Reddit's decision to introduce a new premium membership tier called "Reddit Premium Platinum," which offers additional features and benefits to users for a monthly fee. This move has sparked controversy and criticism from many Reddit users who fear that it will create a two-tier system and undermine the platform's core principles of free and open discussion.

The blackout is organized by moderators of various subreddits who are concerned about the direction Reddit is taking. By making their communities private, they hope to raise awareness among users and encourage discussions about the potential consequences of the new pricing policy.

The protest is not limited to specific types of subreddits; a wide range of communities across various topics are expected to participate. This includes popular subreddits such as r/AskReddit, r/pics, and r/movies, among others. The blackout is expected to significantly impact the overall activity and engagement on the platform for the duration of the protest.

Critics argue that the new pricing policy could lead to a more commercialized Reddit, potentially favoring large corporations and diminishing the influence of individual users. They express concerns that the platform's sense of community and democratic nature could be eroded as a result.

In response to the planned blackout, Reddit released a statement acknowledging the concerns and stating that they are committed to engaging with users to address their feedback. They emphasized the importance of user input in shaping the platform's future and pledged to continue refining their offerings based on community feedback.

The blackout serves as a reminder of the power of online communities and their ability to mobilize for a common cause. Reddit has a history of user-driven protests that have influenced policy changes in the past. The collective action by subreddit moderators highlights the significance of their role in shaping the platform and the importance of user voices in discussions about its future direction.

As the blackout unfolds, it is yet to be seen how Reddit users and the platform's management will navigate this period of heightened tensions. It will likely serve as a critical moment for both sides to engage in open dialogue and find common ground to address the concerns raised by the community.