What happened
Sansec places first confirmed exploitation at 22:20 UTC on September 4, 2026. Adobe published APSB26-146 and Hotfix VULN-39341 on September 7, 2026. Adobe confirmed that CVE-2026-75650, an unauthenticated template-engine vulnerability rated CVSS 10.0, was being exploited in the wild. Adobe distributes the principal hotfix as VULN-39341-composer-patches.zip.
Adobe updated its implementation guidance on September 8, 2026, requiring the patch and rotation of encryption keys and associated credentials. Adobe lists affected Adobe Commerce branches from 2.4.4-2026-aug through 2.4.9-2026-aug and earlier, Adobe Commerce B2B branches from 1.3.3-2026-aug through 1.5.3-2026-aug and earlier, and Magento Open Source branches from 2.4.6-2026-aug through 2.4.9-2026-aug and earlier.
Adobe’s Commerce Cloud verification command is vendor/bin/magento-patches -n status | grep “39341|Status”, and the required VULN-39341 result is Applied. Adobe also instructs operators to rotate the encryption key, administrator passwords, REST, SOAP and GraphQL integration tokens, OAuth client secrets, payment-gateway credentials, database credentials, SSH and deployment keys, privileged service-account credentials and third-party extension API keys.
Sansec observed background processes named [kworker/u:8:0], fc-cache and chronyd, and later observed a second attacker dropping a PHP web shell on affected stores. No standalone public proof-of-concept was available as of September 8, 2026. Attribution posture: no specific threat actor has been publicly linked to exploitation of CVE-2026-75650. The cited public material does not identify every victim or provide a complete infrastructure list. The cited source did not publish the specific operational detail described as Standalone proof-of-concept status.
Why this matters now
The September 8 guidance materially expands the enterprise task from installing a hotfix to conducting credential containment. Adobe says rotating the Commerce encryption key alone does not invalidate credentials an attacker may already have read. Payment gateways, databases, integration tokens, OAuth secrets, deployment keys and extension APIs therefore remain exposed until rotated at their originating systems.
Internet-facing Commerce platforms combine customer data, payment integrations, privileged automation and third-party extensions. Successful unauthenticated code execution can cross application, host and identity boundaries quickly. Retailers operating multiple regional storefronts or outsourced Commerce environments need one consolidated exposure register; otherwise an apparently patched production store may coexist with unpatched development, disaster-recovery or agency-managed instances.
Sansec’s observations establish activity before the vendor hotfix and describe changing implants and a second attacker on affected systems. That makes patch compliance necessary but insufficient. Security leadership must fund a compromise assessment, preserve volatile and application evidence, and define when rebuilding is safer than attempting to validate a modified commerce host in place.
The decision for security leaders
Separate remediation into exposure closure, compromise assessment and credential containment. Patch status answers only the first question. A clean decision requires application and host evidence, review of outbound activity, persistence checks and explicit handling of every secret protected by the Commerce encryption key.
Direct e-commerce, infrastructure, payment, database and integration owners through one coordinated rotation sequence. Unplanned secret replacement can interrupt checkout, fulfilment and deployment pipelines, but delaying rotation leaves reusable credentials valid. Use maintenance controls and staged validation rather than treating availability risk as a reason to defer containment.
Where implant or web-shell evidence exists, preserve forensic data and prefer rebuilding from trusted artefacts. Require external agencies and managed Commerce providers to return instance-level evidence, not a general assurance that patching was completed.
Evidence of closure
- Instance register shows no affected Commerce environment without an approved disposition.
- Hotfix verification output records VULN-39341 as Applied on every in-scope Cloud instance.
- Forensic results document no implant, web shell or unexplained persistence.
- Credential register proves each exposed secret was replaced at its source.
The Security.io assessment
The material change is Adobe’s expanded September 8 instruction that associated credentials must be replaced at their source. This removes any defensible interpretation that encryption-key rotation alone completes remediation and makes identity owners, payment teams and third-party integration managers part of the incident response.
Observed exploitation before the hotfix means organisations cannot use deployment time as proof that they were never exposed. Sansec’s changing process names and second-actor activity also suggest that a narrow signature search may miss modified or secondary persistence. Negative findings need broad host, application, scheduled-task and account review.
The evidence supports confirmed active exploitation and urgent action, but it does not establish compromise of every vulnerable store. Organisations should avoid declaring breach without evidence while refusing equally unsupported clean conclusions. Hotfix verification, compromise hunting and credential replacement produce the strongest defensible closure posture.
Questions for the morning meeting
- Which internet-facing Commerce instances fall within Adobe’s affected branches?
- Can the team prove Hotfix VULN-39341 is Applied on every instance?
- Have implant, web-shell and credential-exposure hunts completed before restoration?
- Which payment, database, deployment and integration credentials require replacement?