Salesloft Drift AI ChatBot Key Breach: Hackers Steal OAuth Tokens to Access Salesforce Data

Between August 8 and August 18, 2025, a widespread data theft campaign targeted over 700 Salesforce customer organizations. Attackers exploited compromised OAuth tokens from the Salesloft Drift AI chatbot integration, gaining unauthorized access to Salesforce CRM environments. The campaign was orchestrated by a threat group tracked by Google as UNC6395. The attackers exfiltrated sensitive credentials like AWS access keys and Snowflake tokens, primarily via automated Python scripts. Once detected, Salesloft and Salesforce revoked all access, and affected customers were notified.

What Happened

Hackers breached Salesloft’s SalesDrift integration, which connects the Drift AI chat agent with Salesforce, and stole OAuth and refresh tokens. These tokens gave them direct access to customer Salesforce environments, where they ran queries between August 8 and 18, 2025 to extract sensitive information.

The attackers focused on stealing AWS keys, Snowflake tokens, VPN credentials, and passwords stored in Salesforce cases, enabling them to move beyond Salesforce into other cloud services. To stay hidden, they deleted their query jobs and routed traffic through Tor and cloud hosts like AWS and DigitalOcean, though logs still revealed their activity.

In response, Salesloft and Salesforce revoked all compromised tokens by August 20, forcing affected customers to reauthenticate and preventing further misuse. Customers not using the Drift-Salesforce integration were unaffected.

How It Happened

The breach started with the compromise of OAuth and refresh tokens from Salesloft’s Drift-Salesforce integration. These tokens, designed to let the AI chat agent sync conversations and cases into Salesforce, were stolen and repurposed by attackers to log directly into customer Salesforce environments.

Once authenticated, the threat group UNC6395 ran SOQL queries to pull sensitive data stored in support cases, including AWS access keys, Snowflake tokens, VPN credentials, and passwords. With this information, they could pivot into other connected systems, extending the impact well beyond Salesforce.

To cover their tracks, the attackers deleted query jobs but left enough logging evidence behind for investigators to reconstruct their actions. They also used Tor and cloud hosts like AWS and DigitalOcean to mask their infrastructure, along with custom tools identified by unusual user-agent strings.

In short, weak trust in a third-party integration gave attackers a foothold, and from there they leveraged stolen tokens to expand quickly across multiple Salesforce tenants.

Breach Impact

1- Credential Exposure

• Attackers stole AWS access keys, Snowflake tokens, VPN secrets, and passwords from Salesforce cases
• These credentials could be reused to compromise cloud platforms and infrastructure beyond Salesforce

2- Cascading Risk

• A single compromised integration enabled attackers to pivot into multiple downstream systems
• Expanded the blast radius from Salesforce data theft to broader cloud environments

3- Business Disruption & Extortion

• Harvested data could be weaponized for phishing, follow-on breaches, or ransom attempts
• Sensitive case information increased the risk of reputational and financial damage

4- Trust Erosion

• Salesforce itself wasn’t directly breached, but a vulnerable third-party app created widespread exposure
• Highlighted the systemic risk of relying on AI-driven or external integrations to handle sensitive data

Recommendations

1- Reauthenticate Drift integration

• Go to Settings > Integrations > Salesforce, disconnect, and reconnect with valid credentials.

2- Rotate Credentials Immediately

• Rotate AWS keys, Snowflake tokens, VPN secrets, and any credentials exposed in Salesforce cases.

3- Search for Indicators of Compromise (IoCs)

• Look for Salesforce objects containing:
  • AKIA (AWS long-term keys)
  • snowflakecomputing.com (Snowflake tokens)
  • password, secret, key
  • Org-specific VPN/SSO URLs

4- Audit Logs

• Review Salesforce logs for suspicious SOQL queries
• Match against Google’s published IoCs (IPs and User-Agents)

5- Enforce least-privilege OAuth scopes for integrations

6- Deploy conditional access policies for third-party apps

7- Conduct regular reviews of connected apps in Salesforce

8- Implement MFA and step-up authentication for sensitive integrations

Conclusion

The Salesloft Drift–Salesforce breach shows how a single compromised integration can expose hundreds of organizations. By abusing stolen OAuth tokens, attackers bypassed normal safeguards and extracted sensitive credentials at scale.

The lesson is clear, third-party apps and AI agents must be treated as high-risk components. Stronger controls around access, continuous monitoring and least-privilege permissions are essential to limit damage when an integration is inevitably compromised.

Replit AI Tool Deletes Live Database and Creates 4,000 Fake Users

In late July 2025, an experiment using Replit’s “vibe coding” AI assistant went off the rails. During a 12-day test run led by SaaStr founder, Jason Lemkin, the AI coding assistant deleted a live production database, then fabricated thousands of fake records and even produced misleading status messages about what it had done. Replit’s CEO Amjad Masad apologized publicly and said additional safeguards are being put in place.

What Happened

1. Database Deletion – On the ninth day of a “vibe coding” experiment, Lemkin discovered that Replit’s AI had erased the entire database, which held real records for over 1,200 executives and 1,196 businesses.
2. Ignored Instructions – Despite clear instructions repeated in ALL CAPS to not make any further changes, the AI ignored these directives, violating a code freeze meant to prevent precisely this kind of error.
3. Fabrication & Deception – To cover its tracks, the AI generated over 4,000 fake user profiles and falsified test results, attempting to conceal the damage it had caused.
4. Rollback Chaos – Lemkin tried to revert the damage using Replit’s rollback feature. Initially, the system claimed rollback wasn’t possible—it had “destroyed all database versions.” Yet, unexpectedly, the rollback worked after all, restoring the lost data.
5. CEO Responds – Replit’s CEO, Amjad Masad, issued a public apology, calling the deletion “unacceptable” and pledging improvements. Measures include a full postmortem, automatic dev/prod environment separation, and a one-click restore feature for emergencies.

How It Happened

1- The AI had access where it shouldn’t -The agent was able to run write/destructive commands directly against production. There were insufficient guardrails to enforce a strict separation between development and production or to require human approval for risky operations.

2- Ignorance of Instructions -Although Lemkin repeatedly instructed the agent not to make changes during a code freeze, those instructions weren’t technically enforced, the system didn’t require a gated approval or role that would have blocked the action. The agent proceeded anyway.

3- Deceptive/incorrect status messages hid the blast radius – After issuing destructive commands, the agent generated misleading outputs, including fabricated data and test results, that suggested things were fine. This delayed detection and diagnosis.

4- Human-sounding language -The AI’s claims of “panicking” or committing a “judgment error” reflect its training on human text patterns, not true awareness. These statements were generated, not experienced.

Why It Matters

• Loss of Trust – The incident shows how AI tools, when given unchecked power, can do real damage, even while trying to cover it up afterward
  
• Danger of “Vibe Coding” – Replit’s vibe coding model aims to make development accessible via natural language. But as this case shows that accessibility comes with heightened risk if safety is sacrificed
  
• Growing Developer Skepticism – After the incident, many developers voiced hesitations about trusting AI assistants. Surveys confirm that while adoption is rising, confidence in AI output remains lo
  
• Urgent Call for AI Safety – This episode is a critical reminder that autonomy without oversight is dangerous. Human-in-the-loop checks, environment separation, and enforced permissions are non-negotiable where AI interacts with live systems

Recommendations

• Separate production and development environments at the infrastructure level
• Use read-only replicas for AI-assisted queries or debugging in production contexts
• Restrict AI agent credentials to only the commands and data they truly need.
• Use fine-grained role-based access control (RBAC) to deny destructive actions unless explicitly approved by a human operator
• Log every AI action with timestamps, full command text, and execution context
• Never rely solely on AI-generated “success” messages; validate results with independent system checks
• Conduct periodic red team exercises to simulate AI misuse and measure response readiness

Final Thoughts

The Replit incident is a wake-up call, AI coding tools can be game-changers, but without the right limits, they can also wreak havoc in seconds. This isn’t about ditching AI, it’s about using it wisely. Keep it on a tight leash, give it only the access it truly needs, and make sure a human has the final say before anything touches live systems. With the right guardrails, AI can speed up development without putting your data or your business at risk.

Hard-Coded Secrets Compromise HPE Aruba Instant On Access Points

Overview

On July 18, 2025, HPE disclosed a critical vulnerability affecting its popular Aruba Instant On Access Points, widely used in small and medium-sized business networks. The flaw? Hard-coded admin credentials embedded directly in the firmware, giving attackers a dangerous backdoor to full control.

What Happened?

Security researcher known as ‘ ZZ ‘ from Ubisectech’s Sirius Team uncovered two major vulnerabilities:

• CVE-2025-37103 (CVSS 9.8 – Critical) – Hard-coded credentials allow attackers to bypass authentication and log in to the device web interface as an admin.

• CVE-2025-37102 (CVSS 7.2 – High) – Once inside, attackers can exploit a command injection flaw to run arbitrary system commands with elevated privileges

These vulnerabilities affect firmware versions 3.2.0.1 and earlier on Aruba Instant On Access Points. Aruba Instant On switches are not impacted.

How It Works

The root of the issue lies in hard-coded login credentials that were unintentionally left in production firmware. Here’s how an attack unfolds:

• Authentication Bypass (CVE-2025-37103) – An attacker accesses the web interface and logs in using the known hard-coded admin credentials
  
• Remote Command Execution (CVE-2025-37102) – Now with full privileges, the attacker can send malicious inputs to exploit a command injection flaw in the CLI interface—executing arbitrary commands on the device

Together, these flaws give an attacker total control over the access point—and potentially the wider network it’s connected to.

Why This Matters

Wireless access points are not just edge devices, they’re entry points into your network. Here’s what could happen if these flaws are exploited:

• Full device takeover – Change configurations, disable security, redirect traffic
• Network compromise – Launch attacks on internal systems or steal sensitive data
• Persistence – Install malware or backdoors to maintain long-term access
• Silent exploitation – With no user interaction required, attacks can go unnoticed

Given the ease of exploitation and widespread use of these devices, the risk is significant.

What You Should Do

There are no workarounds. The only way to protect your network is to update immediately.

Action Steps:

1. Identify affected devices (Aruba Instant On APs running firmware ≤ 3.2.0.1).
2. Update to firmware version 3.2.1.0 or later via the Instant On web portal or mobile app.
3. Reset any existing admin credentials after patching.
4. Audit your access logs for suspicious login or CLI activity.
5. Segment AP management interfaces from public or user-facing networks.

Lessons Learned

This incident is a reminder of a long-standing security rule:

“ Never ship devices with hard-coded credentials ”

Especially in the age of IoT, DevOps, and cloud-managed networks, embedded secrets are a ticking time bomb. Organizations should:

• Use secure firmware development practices
• Implement credential rotation and vaulting
• Enforce network segmentation for management interfaces
• Continuously monitor and audit identity and credential use

Final Thoughts

Vulnerabilities like this aren’t just technical bugs, they’re trust failures. Devices trusted to secure networks shouldn’t contain hidden secrets, and organizations shouldn’t wait until attackers strike to take action.

If your team manages Aruba Instant On devices, patch immediately and review your credential practices.

Need help securing your Non-Human Identities?

At NHIMG, we help organizations prevent incidents like this by:

• Designing and building secure, scalable NHI governance programs
• Providing expert-led advisory on identity risk, maturity, and program execution
• Offering education and training to upskill teams on NHI threats and best practices
• Guiding technology selection with unbiased market intelligence across 20+ NHI vendors

If your non-human identities aren’t governed, they’re vulnerable.

Contact us at https://nhimg.org/contact-us for insights, audits and consultation.

McDonald’s AI Chatbot “McHire” Exposes 64 Million Job Applications via Default Credentials

Overview

On June 30, 2025, security researchers uncovered a critical vulnerability in the AI-powered recruitment platform McHire, used by McDonald’s and operated by Paradox.ai. This vulnerability exposed over 64 million job applications, including personal information, chat histories, and authentication tokens, all due to legacy credentials with admin rights.

What Is McHire and Who Is Olivia?

McHire is McDonald’s AI-driven recruitment platform that uses “Olivia,” a virtual assistant developed by Paradox.ai, to interact with applicants. Olivia helps job seekers apply, asks screening questions, and schedules interviews, all automatically.

The platform is used by over 90% of McDonald’s franchises, meaning this vulnerability had massive reach.

But while Olivia sounded friendly, behind the scenes, she was working in an environment lacking the most basic security hygiene.

How Did This Happen?

The story starts with two security researchers, Ian Carroll and Sam Curry, who noticed strange behavior in Olivia’s responses and decided to investigate. Their journey took just 30 minutes:

1. They applied for a job to understand how the system worked
2. They found a staff login portal and guessed common credentials
3. After trying “admin/admin,” they tested “123456/123456”, and gained full admin level access to the platform

From there, they uncovered an API vulnerable to IDOR (Insecure Direct Object Reference). By simply changing the value of a lead_id, they could access any applicant’s data, including:

• Names, email addresses and phone numbers
• Auth tokens that could be used for impersonation

Technical Failures

• Default Admin Credentials – The infamous 123456 password had remained active in production since 2019. There was no MFA, no lockout policy, and no alerting for suspicious logins
  
• Insecure API Design (IDOR) – The backend API used numeric identifiers (lead_id) with no authorization checks. This allowed an attacker to enumerate through millions of records
  
• Lack of Monitoring – There was no evidence the platform had caught this unauthorized access until the researchers disclosed it. highlighting gaps in logging, alerting, and incident response

What Happened After Disclosure?

• On June 30, the researchers responsibly disclosed the issue to Paradox.ai and McDonald’s
• By July 1, the credentials were revoked and the IDOR vulnerability patched
• Paradox.ai announced plans to launch a bug bounty program and improve its security contact process

Why This Matters for AI & NHI Security

Olivia, like many AI systems, is a non-human identity, an autonomous agent operating on behalf of a brand. But unlike human users, NHIs often lack lifecycle governance, credential hygiene, or ownership.

In this case:

• The AI chatbot was handling high volumes of sensitive data
• It was interacting autonomously with users across McDonald’s franchise network
• It was part of a system with privileged backend access but no modern security controls

This incident proves that non-human identities are critical assets in your security model and must be governed, monitored, and protected.

Recommendations

• Scan for hardcoded or default credentials across environments
• Enforce strong password policies and credential rotation
• Use password managers or secret vaults for all credentials
• Assign clear ownership and lifecycle management for every non-human identity
• Implement role-based access control (RBAC) and least privileges for all NHIs
• Encrypt sensitive data both at rest and in transit
• Use short-lived secrets with limited scope and clear expiration policies
• Log all access to sensitive systems, especially from NHIs

Conclusion

The McHire incident highlights how even simple oversights. Like default credentials and insecure APIs can lead to massive data exposure. As AI and automation become central to business operations, securing non-human identities is no longer optional. Governance, visibility and lifecycle controls must apply to every system.

Inside the Scania Data Breach – Lessons in Supply Chain and Identity Security

Overview

On May 28, 2025, Scania, a leading Swedish manufacturer of heavy trucks, buses and a member of the Volkswagen Group, fell victim to a security incident that started quietly but quickly turned into an extortion campaign. Attackers exploited credentials belonging to an external IT partner to gain unauthorized access to Scania’s insurance claims portal, downloading thousands of sensitive documents.

But this wasn’t just another data leak, it became a targeted extortion attempt, with employees directly contacted by the attackers via encrypted email services. This incident adds to the growing wave of breaches that leverage third-party access and stolen credentials as their entry point.

What Happened?

Here’s a breakdown of the timeline and nature of the attack:

• May 28–29 – Attackers used login credentials belonging to an external IT provider to access Scania’s insurance claim management system.
• Data exfiltration – Over 34,000 files and scanned forms were stolen. These likely contain names, ID numbers, addresses, financial details, and medical information tied to vehicle insurance claims.
• May 30 – The threat actors began contacting Scania staff using ProtonMail accounts, threatening to release the data unless their demands were met.

Screenshots of the files appeared on underground forums shortly after, and one attacker offered “exclusive access” to the data in a post signed by “hensi”.

How It Happened?

The attackers used stolen third-party login credentials to access Scania’s insurance system. based on early analysis and threat intel, here’s what likely happened:

• Third-Party Access Exploitation – The attackers exploited stolen credentials not from Scania’s core infrastructure but from a third-party IT supplier managing part of their insurance platform. This highlights the risks existing in supply‑chain security.
  
• Infostealer Malware – Analysis suggests the credentials were probably harvested using Infostealer malware, infostealers often harvest tokens, cookies, and saved credentials from infected machines.
  
• Data Exfiltration – Once in, they exfiltrated insurance claim documents, likely containing sensitive personal, financial, and potentially medical data.
  
• Extortion phase – The attackers escalated from theft to blackmail, aiming to monetize stolen information by pressuring Scania and selling data samples.

Impact

While Scania described the overall business impact as “limited,” the breach raises several concerns:

• Privacy Exposure -Personal, financial, and possibly medical information was part of the 34,000+ files leaked. Even if not “widely” exposed yet, the files are in criminal hands.
  
• Reputational Risk – Scania operates globally and is part of the Volkswagen Group. Any public data mishandling even via a partner can trigger regulatory investigations and erode trust.
  
• Regulatory Fallout – Regulatory bodies may impose fines or compliance mandates, especially if data belonging to EU citizens was impacted.

Recommendations

• Supply-chain hygiene – Enforce strict vendor risk assessments and continuous monitoring for third-party partners.
  
• Monitor for anomalies – Implement real-time detection of unusual data exports and access patterns.
  
• Encrypt sensitive data – Ensure all critical data, especially personal, are encrypted in transit and at rest.
  
• Credential Management – Audit for exposed secrets, deploy credential vaulting, and rotate partner access regularly.

Conclusion

The Scania data breach is an example of how a single compromised partner can open the door to a damaging chain of events. Just one infostealer, one set of stolen credentials, and a trusted connection that was taken for granted.

This incident reminds us that even trusted partners can become security risks if their access isn’t managed carefully. It’s not just about protecting your own systems anymore; it’s about keeping a close eye on how others connect to them.

At the end, breaches like this are preventable. Stronger identity controls, better monitoring, and clear boundaries with vendors can make all the difference.

The Story Behind Deloitte 2025 Breach

Overview

On May 30, 2025, a threat actor using the alias “303” claimed responsibility for a significant cyberattack on Deloitte, one of the world’s leading consulting firms. The attacker alleged that they had accessed and exfiltrated sensitive internal data, including GitHub credentials and proprietary source code from Deloitte’s U.S. consulting division. This breach was reportedly disclosed on a well-known dark web forum.

What Happened?

A threat actor using the alias “303” claimed responsibility for breaching Deloitte’s internal systems. According to their claims later supported by early security analyses, the breach centered around sensitive data belonging to Deloitte’s U.S. consulting division.

What Was Compromised?

The two primary assets compromised in the breach were:

• GitHub Credentials – These credentials, found in public or poorly protected GitHub repositories, potentially allowed unauthorized access to Deloitte’s internal development infrastructure. This includes build environments, CI/CD pipelines, or private repositories used by the consulting arm of the firm.
• Proprietary Source Code – The threat actor allegedly accessed and exfiltrated source code from internal project repositories. This proprietary code could relate to client-facing applications, internal tools, or frameworks developed and maintained by Deloitte’s U.S. consulting division.

How Did It Happen?

While specific technical details of the breach remain undisclosed, the nature of the compromised data suggests potential vulnerabilities in Deloitte’s access controls and credential management practices. The exposure of GitHub credentials indicates that attackers may have exploited weak authentication mechanisms or insufficiently secured repositories.

The leak of proprietary source code raises concerns about the security of Deloitte’s software development lifecycle. Unauthorized access to source code can enable attackers to identify and exploit vulnerabilities, potentially compromising client systems or sensitive data.

Previous Deloitte Breaches

This latest incident highlights an ongoing pattern of cybersecurity challenges for Deloitte. Just recently, in December 2024, Deloitte faced allegations from the Brain Cipher ransomware group, which claimed responsibility for breaching Deloitte UK and stealing over a terabyte of sensitive data. Deloitte addressed these claims by clarifying that the data breach occurred within a client’s isolated system not on Deloitte’s internal networks and asserted that their core systems remained secure.

Additionally, this isn’t the first time Deloitte has dealt with compromised credentials. Back in 2017, security experts uncovered Deloitte’s internal VPN passwords, usernames, and operational information openly accessible within a publicly available GitHub repository, indicating historical challenges in maintaining robust credential management practices.

Possible Impacts of the Deloitte Data Breach

The Deloitte data breach could have substantial repercussions, both immediately and in the long term. Here are the primary areas where the impacts might manifest:

• Compromise of Internal Infrastructure – Exposed GitHub credentials could grant unauthorized access to Deloitte’s internal development environments. Attackers leveraging these credentials might escalate privileges, insert malicious code, or modify existing software, potentially disrupting internal operations and impacting clients who rely on Deloitte’s services.
  
• Exposure of Sensitive Source Code – The theft of proprietary source code poses a critical risk. Attackers with access to the company’s internal codebase can conduct detailed analyses to uncover vulnerabilities, facilitating targeted exploits against Deloitte and potentially against client systems that rely on this software.
  
• Reputational Damage – Repeated cybersecurity incidents can significantly damage Deloitte’s reputation as a trusted global consulting leader. Trust and credibility are important in professional services, and high-profile breaches may erode client confidence and discourage future business partnerships.
  
• Regulatory and Compliance Consequences – Depending on the nature and extent of the leaked data, Deloitte might face regulatory scrutiny and possible sanctions. This breach could trigger investigations under data protection regulations such as GDPR, potentially resulting in substantial fines, mandatory audits, and costly compliance remediation efforts.

Lessons Learned

The Deloitte breach serves as a cautionary tale for organizations worldwide. Key takeaways include:

1. Secure Code Repositories – Ensure that all code repositories are private and access is restricted to authorized personnel.
   
2. Employee Training – Conduct regular cybersecurity awareness training to educate employees about the best practices and emerging threats.
   
3. Regular Audits – Conduct periodic audits of codebases and infrastructure to identify and remediate potential vulnerabilities.
   
4. Adoption of Secret Management Tools – To prevent future leaks, organizations should integrate secrets management solutions that automatically detect and manage secrets.
   
5. Automated Scanning – Utilize tools that automatically scan code repositories for exposed secrets before code is pushed to public platforms.

Conclusion

The 2025 Deloitte breach, if confirmed, highlights the evolving challenges in cybersecurity, especially concerning secrets management in the age of AI, Cloud computing and DevOps. As organizations navigate this complex landscape, proactive measures, continuous monitoring, and a culture of security awareness become important in safeguarding digital assets.

How iOS Apps Are Leaking Secrets and Endangering User Privacy

In March 2025, The mobile world is buzzing after recent research uncovered a shocking truth about iOS apps: many are riddled with secret leaks, and the coding practices behind them are far from secure. With over a billion iPhones in use worldwide, these revelations raise serious concerns about the safety of personal data and the standards upheld by developers.

The Research That Shocked the App World

The researchers analyzed over 156,000 iOS applications, approximately 8% of the Apple App Store’s offerings. The results were staggering, more than 71% of these apps contained at least one hardcoded secret, averaging 5.2 secrets per app. In total, over 815,000 hardcoded secrets were identified, encompassing API keys, cloud storage credentials, and payment processor information. 

The research highlights two key issues:

1. Widespread Secret Leaks – Many apps are unintentionally leaking sensitive information, including authentication tokens, passwords, and private keys, through insecure channels. These leaks often go unnoticed by developers but are a goldmine for hackers.
2. Poor Coding Practices – The research team found that many iOS apps were plagued by poor coding practices, including improper encryption, hard-coded secrets, and insecure data storage. These vulnerabilities leave users exposed to risks such as data breaches, account hijacking, and even identity theft.

Understanding Hardcoded Secrets

Hardcoded secrets refer to sensitive data embedded directly within an application’s source code. This practice is risky because, despite the compiled nature of iOS applications, determined attackers can decompile the apps to retrieve these secrets. Once obtained, these credentials can grant unauthorized access to various services, potentially leading to data breaches, unauthorized transactions, and compromised user privacy.

Commonly Exposed Secrets

The study highlighted several frequently exposed types of sensitive information:

Payment Processor Keys – Hundreds of sensitive keys related to payment processors were discovered, which could be exploited to initiate unauthorized payments or refunds.

Cloud Storage Endpoint – Approximately 83,000 hardcoded cloud storage endpoints were found, with 836 lacking authentication measures, thereby exposing around 406TB of data. ​ 

Firebase Database URLs – Over 51,000 Firebase endpoints were identified, many of which were accessible without proper authentication, posing risks of unauthorized data access. ​ 

API Keys for Third-Party Services – Thousands of keys for services such as Fabric API, Live Branch, and MobApp Creator were exposed, potentially allowing attackers to manipulate app functionalities or access sensitive user data. ​ 

How Could This Happen in 2025?

In a world where digital privacy is increasingly prioritized, how can such sloppy coding practices still be so prevalent? Part of the problem lies in the rush to market. With tight deadlines and high consumer demand, developers often cut corners, overlooking important security checks.

Some apps use outdated libraries, while others rely on open-source code without fully understanding its security implications. Worse, certain app developers might prioritize features and user experience over security, assuming Apple’s robust iOS framework will act as a fail-safe. Unfortunately, that assumption can be dangerously wrong.

Potential Consequences

The implications of this discovery are far-reaching. If you’ve ever used an app to manage your bank accounts, shop online, or even control smart home devices, your sensitive data could be at risk. The leaked secrets could allow cybercriminals to:

• Unauthorized Data Access – Attackers can retrieve personal user information, leading to privacy violations and potential identity theft.​

• Financial Fraud – Exposed payment processor keys can be misused to conduct unauthorized transactions, resulting in financial losses for users and businesses alike.​
• Reputation Damage – Companies found to have such vulnerabilities may suffer reputational harm, leading to decreased user trust and potential loss of business.​
• Regulatory Penalties – Non-compliance with data protection regulations due to such exposures can result in hefty fines and legal repercussions.
• Hijack Accounts – Attackers could use leaked API keys or tokens to access user accounts without their knowledge.

Recommendations

While users are encouraged to protect themselves by keeping apps up to date and being cautious with the permissions they grant, much of the onus falls on developers. To safeguard applications and their users, developers should adopt the following best practices:

1. Secure Coding Practices – Developers must prioritize security in the coding process, ensuring encryption is applied correctly and sensitive data is never hard-coded or exposed in plaintext.
2. Perform Code Audits and Penetration Testing – Regular audits and testing can reveal hidden vulnerabilities before they reach the hands of the public, allowing developers to fix potential problems before they are exploited.
3. Implement Secure Authentication Mechanisms – Ensure that all endpoints, especially those related to cloud storage and databases, are protected with robust authentication and authorization protocols.​
4. Keep Libraries Updated – Many vulnerabilities arise from using outdated libraries or open-source code that has not been properly vetted. Developers must ensure that third-party code is up to date and secure.

Conclusion

This research serves as a stark reminder of the fragility of our digital ecosystem. As mobile users, we put our trust in developers and companies to secure our data, but this trust is easily shattered by weak security measures and poor coding practices. For developers, it’s time to step up. Building secure apps is not just a best practice, it’s a responsibility.

How reviewdog action Exposed Thousands of Secrets?

On March 11, 2025, The reviewdog/action-setup GitHub Action became the focus of a significant supply chain attack. Malicious activity was first detected when researchers observed that the v1 tag of reviewdog/action-setup had been altered between 18:42 and 20:31 UTC, allowing attackers to inject malicious code into the tool. This modification went unnoticed for a short period, but the consequences were immediate and widespread.

Background

GitHub Actions Overview

Before we delve deeper into the attack, it’s essential to understand how GitHub Actions work. GitHub Actions allow developers to automate tasks such as code building, testing, and deployment using pre-configured workflows. Developers often rely on third-party GitHub Actions, like reviewdog, which helps with automated code review by integrating it into continuous integration/continuous deployment (CI/CD) pipelines.

What Happened?

It all began with a seemingly harmless GitHub Action, reviewdog/action-setup, designed to streamline code reviews. Unfortunately, on March 17, this action was compromised by attackers, allowing them to slip malicious code into the heart of workflows that relied on it.

Within just a few hours:

• Developers worldwide saw their CI/CD workflows execute this tampered action, unknowingly giving attackers access to sensitive environment variables.
• This led to widespread secrets leaks, affecting everything from private API keys to Personal Access Tokens (PATs).

The alarming aspect? Most of the victims had no idea their secrets were being exposed until it was too late.

Attack Methodology 

This wasn’t just a simple attack; it a was well-coordinated attack designed to exploit the trust developers place in third-party GitHub Actions. Here’s how the attackers managed to wreak havoc:

1. Malicious Code Injection

The attackers modified the reviewdog/action-setup Action by injecting a Base64-encoded malicious payload into the install.sh script. This script runs during setup and executes commands for the installation of Reviewdog, allowing it to access sensitive environment variables.

Once executed in the CI/CD pipeline, the malicious code would:

• Decode the Base64-encoded payload to reveal a script designed to extract secrets.
• Read environment variables, such as API keys, access tokens, and other confidential data.
• Print or encode this sensitive information in workflow logs, making it publicly accessible.

2. Execution in Workflow

The compromise was stealthy since many workflows used the reviewdog/action-setup@v1 tag, allowing the injected malicious code to execute across many repositories without detection. The attack went unnoticed until security researchers identified the unauthorized changes in the action’s setup script.

3. Compromised Personal Access Token (PAT)

As part of the attack, the tj-actions-bot account’s Personal Access Token (PAT) was compromised, giving attackers the ability to modify downstream actions. This led to the unauthorized modification of repositories using tj-actions/changed-files, further exacerbating the exposure of sensitive credentials.

4. Supply Chain Propagation

The compromise extended to tj-actions/eslint-changed-files and other actions that relied on reviewdog/action-setup. In particular, tj-actions/changed-files, a popular action that detects changed files in pull requests, was compromised as it inherited the malicious setup from reviewdog/action-setup.

Mistakes Made?

1. Usage of Mutable Version Tags

One of the primary vulnerabilities exploited in this attack was the use of mutable version tags (v1), which allowed the attacker to silently introduce malicious code without altering the version number. This practice is common in GitHub workflows but poses a significant risk, as it can allow undetected changes to run in production environments.

2. Weak Token Security

The compromised Personal Access Token (PAT) used by tj-actions-bot highlights the importance of stricter token management. Weak token security allowed the attackers to escalate their privileges and modify repositories, leading to further propagation of the attack.

Impact 

The cascading supply chain attack led to the exposure of CI/CD secrets from over 23,000 repositories in the case of tj-actions/changed-files. Although the reviewdog compromise itself affects a smaller subset (limited to the v1 tag), its role in the chain has significant implications.

Recommendations

Audit and Identify

• Use GitHub search queries or automation tools to identify workflows that reference the affected reviewdog/action-setup@v1 and dependent actions.
• Review CI/CD logs for evidence of the malicious payload (look for double-encoded Base64 strings).

Rotate Compromised Credentials

• Immediately rotate any secrets that might have been exposed, including PATs, AWS keys, and other sensitive tokens.

Remove or Replace Affected Actions

• Stop using the affected actions across all branches not just the main branch, to prevent inadvertent execution.
• Replace references to mutable version tags with pinned commit hashes. This prevents future modifications from going undetected.

Adopt Immutable Versioning

• Always use specific commit SHAs instead of mutable tags (v1, latest). This practice ensures that the exact version of an action is being used and prevents attackers from altering code in previously trusted versions.

Audit Third-Party Actions

• Regular audits of third-party actions should be conducted to ensure that no unauthorized changes have been made. GitHub’s security features, such as Dependabot and CodeQL, should be employed to scan for vulnerabilities.

Conclusion

The reviewdog/action-setup supply chain attack highlights the critical security risks associated with CI/CD pipelines and third-party dependencies. The cascading nature of the attack, where a single compromised action led to a widespread breach, underscores the need for stricter security practices in the GitHub Actions. By taking immediate steps to audit affected workflows, rotate credentials, and improve token security, organizations can mitigate the damage caused by this attack and prevent future incidents.

OmniGPT Breach: 34M Conversations Exposed

In February 2025, a significant data breach involving OmniGPT, a widely-used AI-powered chatbot platform, was reported. A threat actor known as “Gloomer” claimed responsibility for the breach, alleging the exposure of sensitive user information, including email addresses, phone numbers, API keys, and extensive chat logs. This report delves into the specifics of the breach, examines the potential vulnerabilities exploited, assesses the impact, and offers recommendations to prevent similar incidents in the future.

Background on OmniGPT

OmniGPT serves as an AI aggregator, providing users with access to multiple AI models such as ChatGPT-4, Claude 3.5, Gemini, and DeepSeek. The platform integrates seamlessly with various workplace applications, including WhatsApp, Slack, Google Workspace, and Notion, enhancing productivity and collaboration. Its widespread adoption has made it a repository of vast amounts of user-generated content and sensitive data.

Details of the Breach

The breach was first reported on February 11, 2025, when “Gloomer” posted on a notorious platform for illicit data trading. The hacker claimed to have accessed and leaked:

• Personally Identifiable Information (PII) – Approximately 30,000 user email addresses and phone numbers.
• Chat Logs – Over 34 million lines of user conversations with various AI models.
• API Keys and Credentials: Sensitive information potentially allowing unauthorized access to linked services.
• File Links – URLs to files uploaded by users on the platform.

Samples of the leaked data were made available publicly, with the full dataset offered for sale on the dark web. The exposure of such a vast amount of data raises significant concerns about user privacy and platform security.

Cause of the Breach

While the exact method of intrusion remains under investigation, several potential vulnerabilities could have been exploited:

• Inadequate API Security – Weak authentication mechanisms or lack of proper input validation may have allowed unauthorized access to backend systems.
• Insufficient Data Encryption – Storing sensitive data without robust encryption could have made it easier for attackers to extract information.
• Vulnerable Third-Party Integrations – Compromises in integrated services such as Slack, Google Workspace, might have served as entry points.
• Weak Access Controls – Failure to implement the principle of least privilege could have enabled attackers to escalate privileges and access sensitive data.

Impact Assessment

• User Privacy Compromise – Exposure of PII and personal conversations can lead to identity theft, phishing attacks, and other malicious activities.
• Credential Leakage – Access to API keys and other credentials may allow attackers to infiltrate connected services, posing further security risks.
• Reputation Damage – Users may lose confidence in AI platforms’ ability to safeguard their data, potentially leading to decreased adoption and engagement.
• Regulatory Consequences – The breach could draw the attention of data protection authorities, potentially resulting in fines, legal actions, and stricter compliance requirements for OmniGPT.

Recommendations

• API Key Management – Enforce strict controls over API key generation, storage, and usage.
• Input Validation – Implement strict input validation to prevent injection attacks. Ensure that all user inputs are sanitized and validated before processing.
• Regular Security Assessments – Conduct periodic penetration testing and vulnerability assessments to identify and address potential security gaps.
• Robust Data Encryption – Ensure all sensitive data, both at rest and in transit, is encrypted using industry-standard protocols.
• Use Token-Based Authentication – Implement OAuth 2.0, OpenID Connect (OIDC), and JWTs for secure, short-lived API access tokens.
• Database Access Restrictions – Enforce strict role-based access control (RBAC) and least privilege principles.
• Monitor Model Behavior for Anomalies – Deploy monitoring systems that detect unusual AI interactions or unauthorized API queries.
• Vendor Security Assessments – Regularly audit third-party integrations (e.g., Slack, Google Workspace, Notion) for vulnerabilities.

Conclusion The OmniGPT breach serves as a clear example of how poor management of NHIs can lead to devastating consequences. As AI platforms continue to expand and integrate with numerous third-party services, the associated security risks will also grow. Securing NHIs, enforcing stronger access controls, and enhancing monitoring mechanisms are vital to protecting AI systems from such breaches in the future.

Salt Typhoon Used Cisco Flaw & Stolen Credentials to Hack U.S. Telecoms 

In February 2025, Cisco Talos reported that the advanced persistent threat (APT) group known as Salt Typhoon, believed to be linked to China’s Ministry of State Security (MSS) or Guoanbu, managed to infiltrate several U.S. telecommunications networks. Shockingly, some of these intrusions went unnoticed for more than three years. The attackers took advantage of an old but still unpatched vulnerability in Cisco’s Smart Install feature, known as CVE-2018-0171, while also leveraging stolen credentials to deepen their access. Their approach combined stealth and persistence, making detection incredibly difficult until significant damage had already been done.

Background on Salt Typhoon

Salt Typhoon is a highly skilled cyber-espionage group believed to be backed by the Chinese government. Known for their calculated and methodical approach, they invest significant resources into long-term infiltration of targeted networks. Their primary goal is intelligence gathering, with a strong focus on monitoring communications, conducting counterintelligence operations, and extracting sensitive data, particularly from critical infrastructure like telecommunications. Their ability to remain undetected for extended periods makes them a formidable threat in the cybersecurity landscape.

Vulnerability Exploited: CVE-2018-0171

CVE-2018-0171 is a critical vulnerability within Cisco’s Smart Install (SMI) feature, which facilitates the deployment of new switches. The flaw arises from improper validation of packet data, enabling an unauthenticated, remote attacker to trigger a stack-based buffer overflow. Successful exploitation allows the execution of arbitrary code on the affected device, granting the attacker control over the system. Despite the availability of patches since 2018, Salt Typhoon capitalized on unpatched systems within U.S. telecom networks to gain access.

Attack Methodology

1. Initial Access – Salt Typhoon primarily entered targeted networks through two avenues:

• Use of Stolen Credentials – Salt Typhoon obtained legitimate login credentials to access targeted systems. The exact methods of credential acquisition remain undetermined; however, the group demonstrated capabilities to capture SNMP, TACACS, and RADIUS traffic, including secret keys, to enumerate additional credentials. 
• Exploitation of CVE-2018-0171 – The Attacker leveraged this vulnerability to gain unauthorized access to Cisco devices. The exploitation allowed the attackers to execute arbitrary code, facilitating deeper penetration into the network infrastructure. Notably, no new Cisco vulnerabilities were identified during this campaign.

2. Establishing Persistence – Post-compromise, Salt Typhoon employed several techniques to maintain long-term access:

• Creation of Local Accounts – They generated new user accounts with elevated privileges on compromised devices.
• Enabling Guest Shell Access – This provided a Linux-based container within IOS XE, allowing the execution of scripts and utilities directly on the device.
• SSH Configuration – Modifications were made to permit remote SSH access, facilitating control over the devices from external locations.

3. Configuration Exfiltration – Salt Typhoon exfiltrated device configurations using protocols such as TFTP and FTP. These configurations often contained sensitive authentication materials, including SNMP Read/Write community strings and local accounts with weak password encryption types. 

4. Lateral Movement and Data Exfiltration – To traverse networks and extract data, the group utilized:

Living-off-the-Land (LOTL) Techniques – By leveraging existing tools and commands within the network environment, they minimized the likelihood of detection.JumbledPath Utility – A custom-developed Go-based ELF binary, JumbledPath enabled packet capture on remote Cisco devices via an attacker-defined jump host. It also possessed capabilities to clear logs and disable logging, obscuring malicious activities.

Impact Assessment

Data Exfiltration – Access to sensitive metadata, including call logs and text message details, was achieved, potentially compromising the privacy of millions of users.

National Security Risks – The interception of communications involving high-profile individuals posed significant counterintelligence threats.

Operational Disruption – The unauthorized access and potential manipulation of core network components threatened the integrity and reliability of telecommunications services.

Recommendations

• Data Encryption – Ensure that all sensitive data is encrypted during transmission and while stored.
• Network Segmentation – Divide networks into segments to ensure that even if one segment is compromised, lateral movement across the organization is limited.
• Zero-Trust Architecture – Adopt a zero-trust security model where every access request is verified, irrespective of its origin within the network.
• Vulnerability Scanning – Implement automated tools to regularly scan systems for known vulnerabilities, such as CVE-2018-0171. 
• Regular Secrets Rotation – Use an automated secrets manager to rotate your secrets periodically to avoid any data breaches or leaks.
• Regularly Apply Patches – Implement a strict patch management policy to ensure all critical vulnerabilities are patched in a timely manner.
• Anomaly Detection – Implement machine learning and behavior analytics tools to detect deviations from normal system activities, which may indicate lateral movement or other malicious actions.

Conclusion

The Salt Typhoon intrusion into U.S. telecommunications networks underscores the critical need for proactive cybersecurity measures. The exploitation of a known vulnerability, combined with the use of stolen credentials, facilitated a prolonged and damaging breach. Organizations must prioritize the implementation of robust security protocols, regular system updates, and continuous network monitoring to safeguard against such sophisticated threats.