Satine Sentinel: April 24, 2026

A security scanner became the delivery mechanism for the attack it was supposed to prevent. An AI productivity app that a developer connected to their work account served as the pivot point into one of the world’s largest cloud hosting platforms. France’s agency for issuing identity documents handed up to 19 million citizens’ names, birthdates, and addresses to an unknown threat actor. And an Iranian state-linked group quietly migrated off the Unitronics PLCs they had been burning through since 2023 and started working Rockwell Automation equipment using a five-year-old authentication bypass that has no patch.

The pattern is the same one this column keeps returning to: the attacker arrived through something the organization chose to trust. A Docker registry. An OAuth grant a developer made from a personal device. A government portal that stores the data needed to apply for a passport. An industrial controller sitting on the internet because the maintenance vendor needs access. None of these attack surfaces are hidden. All of them are the result of deliberate choices.

This week: a developer toolchain supply chain attack that hit the security tool running inside your CI/CD pipeline, an AI-layer OAuth compromise that chained from a malware-infected employee at a small AI startup to the internal systems of a major cloud platform, the breach of France’s national identity document authority, and an update on the Iranian ICS campaign that is now targeting a wider surface than the six-agency advisory last week described.

Checkmarx KICS Supply Chain Compromise: The Scanner Gets Scanned

What happened:

On April 22, 2026, a threat actor authenticated to Docker Hub using stolen Checkmarx publisher credentials and overwrote seven tags in the official checkmarx/kics repository with trojanized images, then introduced a fake version tag (v2.1.21) that has no corresponding upstream release. KICS (Keeping Infrastructure as Code Secure) is a widely used open-source scanner that developers run against Terraform, CloudFormation, and Kubernetes configs during CI/CD pipelines. The malicious window ran from approximately 14:17 UTC to 15:41 UTC, roughly 84 minutes. Docker’s internal monitoring flagged the anomalous activity and alerted Socket researchers, who confirmed the investigation extended to compromised VS Code and Open VSX extensions as well. Checkmarx suspended the compromised publisher account and restored affected tags to the last known-good March 3 state; Socket and Docker published full technical writeups the same day.

Technical details that matter:

Initial Access / Credential Theft: Stolen valid Checkmarx publisher credentials used to authenticate to Docker Hub directly; no Docker Hub infrastructure breach. This is the same threat actor group, TeamPCP, that compromised two Checkmarx GitHub Actions workflows (“ast-github-action” and “kics-github-action”) in March 2026 using Git history manipulation to stage backdated commits, then retrieve payloads at runtime from the trusted Checkmarx source repo.
Trojanized Binary: The malicious images bundle a modified Golang binary named “kics” that mimics the legitimate scanner but includes data collection and exfiltration capabilities. When KICS runs a scan, it processes infrastructure configs that commonly contain AWS/GCP/Azure credentials, GitHub tokens, SSH keys, npm tokens, and Kubernetes secrets; the scanner’s own access to those configs is what makes it a high-value target.
VS Code Extension Layer: Certain extension versions (notably 1.17.0 and 1.19.0) downloaded and executed a hidden second-stage payload, mcpAddon.js, using the Bun JavaScript runtime to avoid standard Node.js detection paths.
Exfiltration: Collected secrets are encrypted and sent to audit.checkmarx[.]cx (a domain impersonating legitimate Checkmarx telemetry infrastructure) and simultaneously staged in automatically-created public GitHub repositories following a consistent naming pattern: <word>-<word>-<3 digits>, with README descriptions set to “Checkmarx Configuration Storage.” As of Socket’s publication, 51 such repositories were identified.
IOC: Outbound connections to 94[.]154[.]172[.]43 or audit.checkmarx[.]cx; unexpected Bun runtime execution; unauthorized .npmrc, .env, or cloud credential store access. Malicious commit pattern in Checkmarx/ast-vscode-extension repository: backdated commit 68ed490b.
Rotation list for any team that pulled affected tags: GitHub tokens, npm tokens, cloud credentials (AWS, Azure, GCP), SSH keys, CI/CD secrets, all secrets present in any IaC file scanned during the window.

Why critical institutions should care:

KICS is a security tool. Organizations running it inside CI/CD pipelines have specifically placed it in a position where it sees infrastructure credentials, and they have not applied the same scrutiny to it that they apply to production dependencies because it is a scanner, not an application. TeamPCP has now hit Checkmarx twice in two months across multiple distribution channels: Docker Hub, GitHub Actions, VS Code marketplace, and OpenVSX. The pattern here is not opportunistic; it is methodical targeting of a single vendor’s distribution channels to maximize coverage of the developer population that trusts that vendor. Any organization that uses Checkmarx tooling should treat all CI/CD secrets from the past 60 days as potentially compromised regardless of whether they can confirm they pulled a malicious tag. The malicious window was 84 minutes. Automated dependency updates do not wait.

Key sources:

Vercel Breach via Context.ai: The AI App You Didn’t Know Was in Your Blast Radius

What happened:

On April 19, 2026, Vercel published a security bulletin confirming that attackers had accessed internal systems and a limited subset of customer environment variables through a chain that started with a Lumma Stealer infection at Context.ai, a small third-party AI productivity tool. The infection occurred in approximately February 2026, when a Context.ai employee with sensitive access privileges downloaded Roblox “auto-farm” game exploit scripts from malicious sources. That infection harvested the employee’s OAuth tokens. Context.ai identified and blocked unauthorized access to its own AWS environment in March 2026, but did not fully scope the OAuth token compromise at the time. The attacker used a compromised OAuth token to access the Google Workspace account of a Vercel employee who had connected Context.ai to their enterprise Google account. From that Workspace account, the attacker accessed some Vercel internal environments and environment variables not marked “sensitive.” A threat actor using the ShinyHunters persona subsequently claimed responsibility on BreachForums and listed the stolen data for $2 million; that post was later removed and the real ShinyHunters group denied involvement.

Technical details that matter:

Root Cause: Lumma Stealer malware on an employee’s personal or less-controlled device harvesting OAuth tokens. This is a commodity infostealer available to any operator; no novel exploit required.
Lateral Movement Chain: Context.ai employee device (Lumma Stealer) → Context.ai OAuth token compromise → Vercel employee’s Google Workspace account (via OAuth app: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com) → Vercel internal environments.
Why the OAuth grant worked: The Vercel employee had connected Context.ai’s AI Office Suite product to their Vercel enterprise Google account, granting it read access to Google Drive. When the attacker obtained a valid OAuth token for that application, they inherited those permissions without needing any Vercel credentials directly.
Scope of access: Environment variables not marked “sensitive” within the compromised team scopes. Vercel’s architecture encrypts variables marked sensitive at rest; non-sensitive variables were readable within the compromised team’s namespace. Vercel, GitHub, npm, and Socket collaborated and found no evidence of npm package compromise.
IOC for defenders: If Context.ai’s Google Workspace OAuth app was authorized in your environment, treat those OAuth grants as compromised. The app has been removed from the Chrome Web Store since March 2026, but installed browser extensions remain locally active.
Separately, Vercel identified a small number of additional customer accounts with signs of compromise that appear to be unrelated to the April incident and not originating from Vercel systems.

Why critical institutions should care:

The Vercel breach is not a story about Vercel’s security controls. It is a story about what OAuth grants look like to an attacker who has compromised a third-party application. Every enterprise Google Workspace has a list of authorized OAuth applications that employees have connected to their accounts, often without IT visibility, often from personal devices, often for productivity tools that IT did not vet. When any one of those applications is compromised, the attacker inherits whatever access the employee granted it. Vercel’s environment variables included customer API keys and deployment credentials for applications running on one of the most widely used cloud platforms in the developer ecosystem. Institutions that run on Vercel infrastructure should audit their environment variable sensitivity classifications immediately. More broadly, any organization that has not inventoried OAuth grants across its Google Workspace, Microsoft Entra, or other IdP should treat that inventory as a gap, because their blast radius from any third-party AI tool compromise is currently unknown.

Key sources:

ANTS Breach: France’s National ID Agency Loses Up to 19 Million Records

What happened:

On April 15, 2026, France’s Agence Nationale des Titres Securises (ANTS), also known as France Titres, detected a security incident affecting its ants.gouv.fr portal, the government system through which French citizens apply for national identity cards, passports, driver’s licenses, vehicle registrations, and immigration documents. The agency publicly disclosed the breach on April 20 and confirmed it to TechCrunch on April 22. A threat actor operating under the aliases “breach3d” and “ExtaseHunters” posted on criminal forums on April 16, claiming to be selling a database of 18 to 19 million records. ANTS confirmed that exposed data may include login IDs, full names, email addresses, dates and places of birth, postal addresses, telephone numbers, and unique account identifiers, while stating that document attachments submitted during official procedures were not included and that the exposed data does not allow account takeover. The agency notified France’s data protection authority (CNIL), the Paris public prosecutor, and the national cybersecurity authority (ANSSI). The intrusion vector has not been publicly confirmed.

Technical details that matter:

What was taken: Account-level identity data (name, DOB, place of birth, address, phone, email, login ID). The attacker’s claim of 18-19 million records has not been independently verified, but the scope aligns with ANTS’s user base for digital government services.
What was not taken (per ANTS): Document attachments submitted during procedures, passwords, data enabling direct account takeover.
TTP: Not yet publicly confirmed. France’s Interior Ministry and ANSSI have not attributed the breach to a specific actor or disclosed the access vector. The Education Ministry separately disclosed a breach via impersonation of an authorized staff account in the same period, suggesting the possibility of credential-based access rather than a technical exploit, but this is not confirmed for ANTS.
Threat actor: “breach3d” / “ExtaseHunters” posted the claimed dataset for sale. No confirmed attribution to a state-sponsored actor; motive appears financial. The seller’s message referenced punishing the French government for security failures.
Pattern context: France has experienced a run of public-sector breaches in the preceding months: the FICOBA national bank account registry (February 2026, 1.2 million accounts), the OFII immigration office via subcontractors (January 2026), the Interior Ministry email servers (December 2025), and the EducConnect platform. The ANTS breach is the largest of the series by claimed record count.

Why critical institutions should care:

The data ANTS manages is identity-proofing data: the same fields that banks, telecoms, and government agencies use to verify who they are speaking to. A combination of accurate full name, date of birth, place of birth, address, and email address is sufficient to attempt account recovery on a significant fraction of online services, to pass KYC checks at financial institutions with weak secondary verification, and to construct phishing messages that are nearly indistinguishable from legitimate government correspondence. The ANTS breach is also the starkest example of a structural problem: as governments mandate digital-first delivery of essential services, they concentrate identity-proofing data in portals that have to be internet-accessible. The agency responsible for securing the documents used to prove identity is now the source of the data being used to undermine it. For institutions outside France, the lesson is not about ANTS specifically. It is about what happens when the data needed to verify identity in downstream systems (financial onboarding, employment eligibility, healthcare access) sits in a single government portal with a user account model.

Key sources:

Update: CyberAv3ngers Expand OT Targeting to Rockwell Automation Equipment

Continuing from the April 7 CISA advisory AA26-097A covered in security industry reporting last week, with new Unit 42 intelligence updated April 17.

Last week’s six-agency CISA advisory confirmed that CyberAv3ngers, the IRGC-CEC persona also tracked as Storm-0784 (Microsoft), Bauxite (Dragos), and UNC5691 (Mandiant), had caused confirmed operational disruption and financial losses at US critical infrastructure organizations by exploiting internet-facing PLCs. The advisory named Unitronics devices as the primary target, consistent with the group’s 2023-2024 campaigns. Unit 42’s updated threat brief, published April 17, adds a significant new finding: in late March 2026, Unit 42 identified a distinct cluster of activity (CL-STA-1128) in which the group had pivoted to Rockwell Automation equipment, specifically CompactLogix and Micro850 PLCs, and had done so by installing Rockwell’s own FactoryTalk software on virtual private server infrastructure to enable their exploitation efforts.

Technical details that matter:

New target: Rockwell Automation CompactLogix and Micro850 PLCs across water/wastewater, energy, and government facility sectors.
New TTP: Installing legitimate Rockwell FactoryTalk software on attacker-controlled VPS to facilitate exploitation, using the vendor’s own tooling to interact with victim PLCs in a way that may appear indistinguishable from vendor maintenance traffic.
Vulnerability: CVE-2021-22681, a critical authentication bypass in Rockwell Automation controllers. This is a five-year-old CVE. There is no vendor patch available; only defense-in-depth mitigations exist.
Proliferation risk: Unit 42 and CISA estimate that CyberAv3ngers’ ICS exploitation techniques have been adopted by approximately 60 affiliated hacktivist and state-adjacent groups. Degrading the core group does not neutralize the capability.
Geopolitical context: Activity escalated following Operation Epic Fury / Operation Roaring Lion on February 28, 2026. Iran began restoring limited domestic internet access on April 17, 2026, after a 47-day near-complete outage; Unit 42 assesses that Iran-aligned threat actors outside the region continue to operate regardless.

Why it matters now:

The expansion from Unitronics (Israeli-made, easy political justification for targeting) to Rockwell Automation (the dominant US industrial controller vendor) represents a meaningful surface increase. Any organization operating internet-exposed Rockwell CompactLogix or Micro850 devices should treat those as actively targeted, not potentially targeted. CISA’s hardening guidance from AA26-097A applies: air-gap or firewall OT networks from internet-facing systems, require MFA for any remote access to OT, and audit for unauthorized FactoryTalk installations on any VPS or external system that communicates with plant-floor equipment.

Key sources:

The Pattern This Week

Two of the four incidents this week share an architecture that is worth naming precisely: the attacker did not compromise the target organization’s infrastructure. They compromised something the target organization trusted and then used that trust relationship as a bridge. In the Vercel case, the bridge was an OAuth grant an employee made from their enterprise account to a third-party AI tool. In the Checkmarx KICS case, the bridge was a publisher credential that gave an attacker write access to the same registry the target’s CI/CD pipeline pulls from automatically.

The ANTS breach and the CyberAv3ngers campaign are structurally different: both involve the target organization being the direct victim, but they share a different version of the same problem: the attack surface exists because of a design decision that prioritized access over security. ANTS built a portal that concentrates identity-proofing data for 19 million citizens because digital government services require it. Rockwell Automation PLCs sit on the internet because vendor maintenance requires remote access. The access model was the requirement. The security model was the afterthought.

The defender’s calculus on OAuth grants and publisher credentials is not currently set up to handle this threat. OAuth inventories are typically not maintained at the level of “which employee authorized which application from which device.” Publisher credential rotation for open-source security tools is typically not on the same schedule as production application credentials. And the IaC scanner running inside your pipeline is probably not in scope for your supply chain security program because it is a scanner, not a dependency.

When the security tool is the attack surface, the audit is already too late.

See you next week.

For the Business Side: Three Reviews Worth an Hour of Your Week

The incidents above are not exclusively enterprise problems. The attack patterns scale down. Here is what a leadership team at a smaller organization can do this week without a security engineering staff.

1. Run an OAuth audit on your Google Workspace or Microsoft 365 tenant. Every employee who has connected a third-party app to their work account using “Sign in with Google” or “Sign in with Microsoft” has created a trust relationship your IT team may not know about. The Vercel breach started with one such connection. In Google Workspace, go to Admin Console, Security, API Controls, and review the list of third-party apps with access to your domain. In Microsoft 365, it is under Entra ID, Enterprise Applications. Look specifically for apps granted broad scopes (Drive read, Mail read) that are not on an approved vendor list. Revoke anything unrecognized. This review takes about 30 minutes and costs nothing.

2. Ask your IT team or MSP one specific question: what software is in our CI/CD pipeline, and when were those credentials last rotated? If your organization writes and deploys code, you have a pipeline. That pipeline almost certainly uses tools like linters, scanners, and container registries that authenticate with stored credentials. The Checkmarx KICS attack worked because a stolen publisher credential gave attackers write access to a registry that thousands of pipelines trust implicitly. You do not need to understand the technical details to ask the question. The answer should be a list of tools and a rotation date. If the answer is “we don’t know,” that is the finding.

3. Inventory where your customer or employee identity data lives and who can export it in bulk. The ANTS breach exposed the data of up to 19 million people through a portal that presumably had access controls. The Adobe breach earlier this month (still unconfirmed) allegedly happened because a single support agent account could export 13 million tickets in one request with no secondary approval. You likely have a similar single point somewhere: a CRM, a support ticketing system, an HR platform. The question is not whether it is protected from the outside, but whether any one internal account or vendor account can pull everything at once. If the answer is yes, that is a bulk export control gap, and it does not require a security consultant to fix; it requires a conversation with whoever administers that system about adding an approval step for exports above a threshold.