{"schema_version":"1.0","service":"Publicasta","type":"article","id":604,"slug":"adobe_commerce_magento_cve_2026_75650_patch_and_investigate","title":"CVE-2026-75650 in Adobe Commerce and Magento: Patch the Store, Then Investigate It","excerpt":"Adobe says CVE-2026-75650 is being exploited in the wild. The emergency fix closes a critical unauthenticated code-execution path, but merchants must also determine whether attackers reached the store before the hotfix was available.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=en","image":{"url":"https://publicasta.com/storage/projects/9/pages/604/2026/09/6d8f9035-e78e-4dcb-9cd1-e2e5c85e1517.webp","alt":"Editorial cybersecurity illustration of an e-commerce storefront protected by a patch and shield against network threats"},"publisher":{"id":9,"slug":"cybersecurity","name":"Cybersecurity Without Panic","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-09-13T17:26:19+00:00","updated_at":"2026-09-13T17:26:19+00:00","content_markdown":"Adobe has issued an emergency hotfix for CVE-2026-75650, a critical vulnerability in Adobe Commerce and Magento Open Source that can allow unauthenticated remote code execution. Adobe rates the flaw at CVSS 10.0 and says it is being exploited in the wild. The Australian Cyber Security Centre and Singapore’s Cyber Security Agency have also urged affected organisations to patch immediately.\n\n ![Editorial cybersecurity illustration of an e-commerce storefront protected by a patch and shield against network threats](https://publicasta.com/storage/projects/9/pages/604/2026/09/6d8f9035-e78e-4dcb-9cd1-e2e5c85e1517.webp)\n\n For merchants, the important distinction is between closing the vulnerability and proving that the store was not already compromised. The first is a software-maintenance task. The second is an incident-response task. A store that was exposed during the exploitation window cannot be treated as clean merely because its patch status now looks correct.\n\n This is a materially different problem from a routine monthly update. The public reporting describes exploitation beginning before Adobe’s September 7 hotfix, and the researcher who disclosed the issue says attackers have been changing payloads while targeting live stores. The safest response is therefore a short, ordered sequence: identify every affected installation, apply the vendor fix, preserve evidence, inspect the host and application, rotate secrets that may have been exposed, and only then return the storefront to normal operation.\n\n ## What CVE-2026-75650 affects\n\n CVE-2026-75650 is an improper-neutralisation flaw in a template engine. Adobe classifies its impact as arbitrary code execution, says authentication is not required, and assigns the issue a CVSS 3.1 base score of 10.0. The score reflects a network-reachable attack path with no required privileges or user interaction and potentially high impact on confidentiality, integrity and availability.\n\n The affected product family includes Adobe Commerce, Adobe Commerce B2B and Magento Open Source. Adobe’s September 7 bulletin lists Adobe Commerce versions 2.4.4 through 2.4.9, including releases identified with the 2026-August build marker, as affected. It lists Adobe Commerce B2B versions 1.3.3 through 1.5.3 and Magento Open Source versions 2.4.6 through 2.4.9 in the affected range. Adobe’s advisory is the authority for the exact package and build combination, so a merchant should compare the running installation and deployed code against that bulletin rather than rely on a product-family name alone.\n\n The Australian Cyber Security Centre adds an operational detail that matters during triage: exploitation requires the `/graphql` endpoint to be exposed. That does not make an Internet-facing store safe if GraphQL is disabled only in a development assumption, selectively filtered, or reachable through a load balancer, CDN, alternate hostname or legacy route. Teams should verify exposure from the actual public deployment and from any administrative or staging environments that are reachable from outside the trusted network.\n\n The affected software is used to operate online storefronts, process customer orders and connect payment, fulfilment, analytics and other business systems. The vulnerability is therefore not limited to the web server. A successful compromise could create a path into credentials, integration tokens, customer-facing application data, order workflows or other services available to the Commerce process. The likely business impact depends on the privileges of the service account, the host configuration and the secrets stored or accessible from the application.\n\n ## Why the timing changes the response\n\n Adobe published APSB26-146 on September 7, 2026, with its highest priority rating. Adobe’s bulletin says the company is aware of exploitation in the wild. Sansec, which published its research on September 5, reported that it observed attacks beginning September 4 and described the issue as an unauthenticated remote-code-execution zero-day at the time of disclosure. Sansec’s page was updated on September 13 and says the emergency fix was released three days after the first confirmed exploitation.\n\n Those dates create a straightforward risk boundary. Any store that was reachable during the period before the fix was deployed needs an exposure assessment, even if no obvious outage occurred. An attacker who gains code execution does not need to deface a storefront or interrupt checkout to cause harm. They may collect credentials quietly, install a web shell or background process, alter application logic, create persistence, or use the store as a stepping stone. A normal customer experience is not evidence that the host is clean.\n\n The absence of a publicly confirmed campaign targeting a particular industry should not be read as reassurance for individual merchants. The Australian advisory says it has information about active exploitation but no indication that one specific sector is being targeted. That wording means the issue is broad rather than sector-specific: every organisation running the affected platform should make its own exposure decision from versions, endpoint reachability, logs and deployment history.\n\n ## The first decision: patch or contain\n\n If the store is affected and the hotfix can be applied safely, the immediate action is to follow Adobe’s installation instructions for the CVE-2026-75650 hotfix. Sansec identifies the fix as Adobe hotfix `VULN-39341`, delivered as a Composer patch. The exact package, supported release and deployment method should come from Adobe’s release notes and the merchant’s support agreement. Do not substitute a patch copied from an unverified forum post or assume that an ordinary `security:patch-status` result proves that this emergency fix is installed.\n\n Before changing production, take a protected backup of relevant application files, configuration, databases and logs. Record the current version, package lockfile, deployed commit or artifact identifier, running PHP and web-server versions, and the time the snapshot was taken. Preserve a copy outside the potentially compromised host. This gives responders something to compare after the change and helps distinguish a patching side effect from an existing intrusion.\n\n If the hotfix cannot be applied immediately, reduce exposure while the deployment is prepared. The Australian advisory recommends updating to a version that includes the patch when necessary and, if no patch is available for the version in use, restricting and monitoring access. In practice, this can mean temporarily limiting public access to the storefront, restricting the vulnerable endpoint at a trusted edge control, or placing the site in a controlled maintenance mode. A Web Application Firewall rule may reduce opportunistic traffic, but it should be treated as a compensating control, not a replacement for Adobe’s fix.\n\n Teams should be cautious with unsupported branches. Sansec reports that Adobe’s tested hotfix coverage is tied to supported 2026-August releases and says that older branches are affected but not verified by Adobe in the same way. If an organisation is on an out-of-support version, the responsible choice is to involve the Commerce maintainer or qualified incident-response provider, test a supported upgrade or reviewed backport, and avoid making an untested production change while the store is actively serving transactions.\n\n ## Patching is not the end of the job\n\n The most common operational mistake in an actively exploited vulnerability is to stop at the version check. A patch prevents the known path from working again. It does not remove code that was written before the patch, undo credentials that were copied, or reveal which external systems were accessed by a compromised process.\n\n Start the investigation with a precise timeline. Identify when each Internet-facing Commerce instance was vulnerable, when the `/graphql` endpoint was reachable, when the first signs of suspicious requests appeared, when the hotfix was applied and whether the application was restarted or redeployed afterward. Include CDN, WAF, reverse-proxy, load-balancer, web-server, PHP-FPM, application, operating-system, scheduled-task and cloud audit logs. Use a consistent time zone and retain the original files before filtering or rotation.\n\n Look for evidence at several layers rather than relying on a single signature. At the edge, review unusual requests to GraphQL, bursts of requests that do not resemble normal storefront traffic, unexpected user agents, repeated errors and traffic from hosting providers or networks not associated with legitimate customers. In the application, examine template changes, failed-payment notification activity, unexpected CMS or configuration edits, new administrator accounts, changes to integration permissions and unusual writes to report, media or cache locations. In the host, look for new processes, new scheduled tasks, modified startup files, unexpected PHP files and outbound connections that the Commerce process would not normally make.\n\n Sansec’s report describes a two-stage pattern in which an attacker poisons code associated with Magento’s template system and later causes Magento to render that code through a failed-payment notification path. That high-level behavior gives defenders useful questions to ask without attempting to reproduce the exploit: did failed-payment notifications suddenly increase, did template-related data change outside a normal deployment, and did a Commerce worker make an unusual file write or outbound connection around the same time? A signal is not proof on its own. Declined payments, extensions and scheduled maintenance can produce similar events, so findings must be correlated with deployment records and request logs.\n\n Do not paste sensitive logs, customer information, session data or secret values into public issue trackers while seeking help. Share only the minimum sanitized evidence with Adobe support, a trusted incident-response provider or the relevant national cyber authority. The Singapore advisory points administrators to the vendor bulletin and NVD record, while the Australian advisory gives affected organisations a channel for assistance and incident reporting.\n\n ## Secrets that may need rotation\n\n If the investigation finds exploitation, or if the store cannot establish that exploitation did not occur, rotate credentials in an order that limits the attacker’s opportunity to follow the change. First protect the identity and administrative systems used to manage the host and deployment pipeline. Then rotate the Commerce encryption key and every credential that may have been protected by, derived from or stored alongside it.\n\n The set can include administrator passwords, REST, SOAP and GraphQL integration tokens, OAuth client secrets, payment-gateway credentials, database passwords, SSH keys, deployment keys, cloud credentials and third-party extension API keys. Rotate them at their source, not merely by editing a value in the Commerce configuration. For example, changing a payment credential inside the store does not invalidate the old key at the payment provider; the provider must issue or revoke the credential. The same principle applies to cloud IAM, source control, monitoring, shipping and marketing platforms.\n\n Rotation should be accompanied by access review. Remove unused integrations, reduce privileges, shorten token lifetimes where practical, confirm that old credentials have been revoked, and inspect authentication logs for use after the last legitimate deployment. If the same secret was reused in another environment, treat those environments as exposed until checked. A key rotation that leaves a forgotten copy active in a staging host or CI variable only creates the appearance of recovery.\n\n Changing the Commerce encryption key alone is not a complete response. It can protect future values written with the new key, but it cannot retrieve or erase anything an attacker already read. It also does not remove a web shell, a scheduled task, a modified extension or a stolen session. Credential rotation belongs after evidence preservation and alongside host remediation, not in place of them.\n\n ## Who needs to act\n\n Merchants operating Adobe Commerce or Magento Open Source should inventory every storefront, regional deployment, staging site, disaster-recovery copy and partner-managed instance. A company may know about its main shop but miss a dormant brand site, an internal order portal or a cloud deployment maintained by an agency. The inventory should record the exact software branch, public hostnames, GraphQL exposure, patch state, owner and last verified review.\n\n Managed-service providers and e-commerce agencies should notify customers, identify shared operational dependencies and prove which environments were patched. A provider’s statement that the platform is “up to date” is weaker than a deployment record naming the hotfix, the affected instance and the verification time. Customers should ask for that evidence and for confirmation that logs were preserved if the service was exposed before the fix.\n\n Payment, fulfilment, customer-support and analytics teams should be involved when there is evidence of code execution or secret exposure. Their systems may not run Magento, but they may trust its API credentials or accept events from the store. The security review should therefore cover downstream tokens, webhook signing secrets, service accounts and unusual activity in connected systems.\n\n Security teams should treat the issue as both vulnerability management and incident response. Vulnerability management answers whether the software is now protected. Incident response answers whether the organisation was already affected. Keeping those workstreams separate prevents a common failure mode in which a successful patch is mistaken for a successful investigation.\n\n ## What not to infer from the available evidence\n\n CVE-2026-75650 is serious, but the facts do not justify every possible claim. Public reporting confirms active exploitation and a critical unauthenticated execution path. It does not by itself prove that every Magento shop was breached, that customer payment data was stolen from every victim, or that one named group is responsible for all observed activity. Merchants should avoid publishing those conclusions without evidence from their own environment.\n\n Likewise, the presence of a suspicious IP address in a log does not prove that the request succeeded, and the absence of a known indicator does not prove that it failed. Attackers can change infrastructure and payloads. Detection should combine request evidence, application effects, file and process changes, authentication records and the time of deployment. Where uncertainty remains, preserve the host and escalate for forensic review instead of deleting suspicious files immediately.\n\n The same caution applies to mitigations. A CDN rule, a WAF signature, a disabled endpoint or a network restriction may lower risk, but each control can be misconfigured or bypassed through an alternate route. A compensating control should have an owner, an expiry date and a verification test. It should not become a permanent excuse for running an unsupported and unpatched storefront.\n\n ## A practical response sequence\n\n For a store that is still exposed, the sequence is simple enough to assign during an incident: identify the instance and owner, restrict access if the hotfix cannot be applied at once, preserve logs and a clean backup, apply Adobe’s CVE-2026-75650 hotfix, verify the deployment from the running artifact, and review public reachability again. Do not restart by deleting evidence or by rebuilding from an unverified backup.\n\n For a store that was patched after September 4, treat the pre-patch period as an investigation window. Compare edge requests with application logs, inspect template and CMS changes, review failed-payment notifications, search for unexpected files and scheduled tasks, examine outbound connections, and check administrative and integration authentication. If there is any credible sign of execution, isolate the host or move the storefront to a known-good environment while response work continues.\n\n For a store with confirmed or probable compromise, preserve the affected system, rotate credentials at their issuing systems, rebuild from trusted artifacts when appropriate, review connected services, notify customers or regulators if required by applicable law, and document the evidence supporting the final risk decision. The recovery plan should include monitoring after restoration, because patching and rebuilding do not guarantee that every dependent account has been secured.\n\n ## The useful lesson for e-commerce security\n\n The immediate lesson is to apply the Adobe hotfix. The broader lesson is about the difference between a clean patch signal and a clean environment. A vulnerable storefront can become an identity and payment-system problem when the application has access to secrets, customer workflows and automated integrations. The security boundary is not just the Commerce package; it includes the server, deployment pipeline, extensions, endpoints, credentials and connected services around it.\n\n CVE-2026-75650 also shows why an emergency fix needs an evidence plan. When exploitation starts before a vendor patch exists, the organisation must do two things in parallel: reduce the remaining attack surface and determine what happened during the exposure window. That approach produces a calmer and more defensible result than either panic-driven shutdowns or a reassuring but unsupported claim that a patched version means the incident is over.\n\n For affected merchants, the decision is therefore clear. Patch with Adobe’s supported hotfix as a priority, confirm that the fix is present in the live deployment, and investigate every instance that was exposed before patching. If suspicious activity appears, assume that secrets may have been read until the relevant issuing systems confirm rotation and revocation. The storefront can return to normal when the software is fixed, the environment has been examined, connected credentials are controlled and the evidence supports that conclusion.","available_translations":[{"language":"ar","title":"CVE-2026-75650 في Adobe Commerce وMagento: رقّع المتجر ثم حقّق في ما حدث","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=ar"},{"language":"de","title":"CVE-2026-75650 in Adobe Commerce und Magento: Shop patchen und anschließend untersuchen","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=de","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=de","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=de"},{"language":"en","title":"CVE-2026-75650 in Adobe Commerce and Magento: Patch the Store, Then Investigate It","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=en","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=en","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=en"},{"language":"es","title":"CVE-2026-75650 en Adobe Commerce y Magento: parchea la tienda y después investígala","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=es","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=es","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=es"},{"language":"fr","title":"CVE-2026-75650 dans Adobe Commerce et Magento : corriger la boutique, puis l’enquêter","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=fr"},{"language":"pl","title":"CVE-2026-75650 w Adobe Commerce i Magento: załataj sklep, a potem go zbadaj","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=pl"},{"language":"ru","title":"CVE-2026-75650 в Adobe Commerce и Magento: сначала закройте уязвимость, затем расследуйте инцидент","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=ru"},{"language":"zh","title":"Adobe Commerce 与 Magento 遭遇 CVE-2026-75650：先修补商店，再调查入侵迹象","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=en","html":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=en","canonical":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=en","markdown":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=en","json":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}