Two critical flaws — one in Apple's built-in remote desktop service, one in SAP's e-commerce platform — went from security advisory to real-world attacks in under a week. The patch window is now measured in days, not months.
August 2026 has produced two exploitation stories that belong side by side. In the first, attackers are rooting internet-exposed Macs through an authentication bypass in macOS Screen Sharing and installing cryptocurrency miners. In the second, attackers began probing a maximum-severity remote code execution flaw in SAP Commerce Cloud just three days after SAP shipped the fix.
Neither flaw is a textbook zero-day. Both were patched before public exploitation was observed. That distinction matters, and it is arguably the more uncomfortable finding: attackers did not need a secret exploit or an unknown bug. They needed a published advisory and organizations that had not yet applied it.
What happened
macOS Screen Sharing — CVE-2026-65400
Apple released an out-of-band update on 6 August 2026 fixing an authentication flaw in Screen Sharing, the remote desktop feature built into macOS. Apple described the issue as an authentication problem resolved through improved state management, and shipped fixes in macOS Tahoe 26.6.1, macOS Sequoia 15.7.9, and macOS Sonoma 14.8.9.
The Netherlands' National Cyber Security Centre (NCSC-NL) published an advisory the following day urging organizations to update. On 12 August, it revised that advisory to confirm something more serious: it had received a report of active abuse against multiple systems where TCP port 5900 was reachable from the internet. In every case reported to the agency, attackers obtained root access and installed a Monero cryptocurrency miner.
The severity assessment has since been rewritten. CISA originally scored the flaw at 7.1 on 6 August, using a vector that assumed the attacker needed some level of privilege and could achieve only partial impact. On 14 August, CISA replaced that with a vector requiring no privileges and granting full compromise of confidentiality, integrity, and availability — raising the score to 9.8 (critical). A day later, its assessment of the flaw changed from "not automatable" to automatable, which is consistent with unattended Macs being compromised at scale for mining.
CVE-2026-65400 is also not an isolated bug. In late July, Apple patched at least four other issues in screensharingd, the daemon behind Screen Sharing. Three received CVE identifiers. According to reporting, the fourth was fixed silently and was the most severe of the group, allowing unauthenticated attackers to achieve remote code execution as root.
SAP Commerce Cloud — CVE-2026-58231
On 11 August 2026, as part of its August Security Patch Day, SAP published Security Note 3771065, addressing a vulnerability in the Data Hub Adapter extension for SAP Commerce Cloud. The flaw carries a CVSS score of 10.0 — the maximum possible.
Three days later, on 14 August, threat intelligence firm Defused reported the first exploitation attempts hitting its honeypots. At that point there was no public proof-of-concept exploit and no prior report of in-the-wild abuse. KEVIntel, which operates its own sensors and private honeypots, independently confirmed seeing attacks, and noted on 15 August that a PoC had since become available. SAP told BleepingComputer it was aware of the reports and investigating.
Affected versions are SAP Commerce Cloud COM_CLOUD 2211 and COM_CLOUD 2211-JDK21. As of this writing, neither CVE-2026-58231 nor CVE-2026-65400 has been added to CISA's Known Exploited Vulnerabilities catalog.
How the attacks work
In plain terms, both flaws let an attacker skip the front door.
macOS Screen Sharing uses the VNC protocol over port 5900 and relies on a challenge-response authentication process (Secure Remote Password) to verify who is connecting. Analysis by security firm Huntress found that an attacker can cause the service to treat an unauthenticated connection as though it had already passed authentication — a state machine desynchronization. The connection is then handled with privileged access.
The critical operational detail: because the bypass happens before normal authentication is evaluated, the hardening steps most administrators would reach for do nothing. Rotating the Screen Sharing password, disabling legacy VNC password access, and removing authorized user accounts all sit downstream of the code path the flaw defeats. The attacker never reaches them. Patching or disabling the service are the only effective responses.
SAP Commerce Cloud's flaw combines two weaknesses: insufficient authorization checks and insufficient input validation. An unauthenticated attacker can abuse a default authentication client to reach functions in the Data Hub Adapter that do not properly validate what they receive, then submit crafted input to those functions to execute arbitrary code and compromise internal components. No credentials and no user interaction are required.
Two terms worth defining:
- Authentication bypass — the system is tricked into believing you have already proven your identity.
- Data Hub Adapter — the SAP Commerce Cloud component that imports and exchanges data with other systems, such as ERP or inventory platforms. It sits at an integration boundary, which is precisely why compromising it is valuable.
Why it matters
The window between patch and attack has collapsed. Three days for a maximum-severity SAP flaw, roughly a week for the macOS bug. Monthly patch cycles and quarterly change windows do not operate on that timescale.
A public proof-of-concept is an accelerant, not a prerequisite. Attackers began probing the SAP flaw before any PoC was published — the advisory itself provided enough direction. On the macOS side, the appearance of public exploit code coincided with a visible jump in exploitation.
Cryptomining is not a harmless outcome. A miner is evidence that an attacker achieved root on the machine and could deploy anything. Cryptojacking is often what commodity actors do with access they cannot immediately monetize any other way — and access can be resold.
Severity scores are provisional. CVE-2026-65400 was rescored from high to critical eight days after disclosure. Teams that triaged it once, at 7.1, and moved on may have deprioritized a bug that turned out to be pre-authentication root access.
Who is affected
macOS (CVE-2026-65400):
- Any Mac running macOS Tahoe, Sequoia, or Sonoma below the fixed versions with Screen Sharing enabled.
- Highest risk: systems where port 5900 is reachable from the internet. Huntress identified tens of thousands of potentially exposed Macs, with internet-hosted bare-metal Apple systems — Mac cloud hosting, CI/CD build fleets, remote-access endpoints — particularly prominent.
- Screen Sharing is off by default, so this is not a universal exposure. It is an exposure wherever the feature was turned on and left reachable.
SAP (CVE-2026-58231):
- SAP Commerce Cloud (formerly Hybris) deployments on COM_CLOUD 2211 or 2211-JDK21 with the affected Data Hub Adapter extension enabled.
- Most urgent: deployments where the Data Hub import functionality is reachable from an untrusted network. This platform typically underpins retail and B2B storefronts and integrates with ERP, CRM, payments, inventory, and fulfilment systems.
What attackers can do
On a compromised Mac: root access, which in observed cases has been used to install a Monero miner. With that level of access, an attacker can also open applications remotely, read files, change security settings, install persistence, and use the host as a foothold into the surrounding network.
On a compromised SAP Commerce Cloud instance: arbitrary code execution and compromise of internal components, with high impact to confidentiality, integrity, and availability. Because of what the platform connects to, realistic follow-on objectives include theft of customer and order data, tampering with pricing or transactions, ransomware staging, and lateral movement into ERP and other back-end systems.
For historical context: CVE-2025-31324, a comparable CVSS 10.0 flaw in SAP NetWeaver exploited in 2025, was weaponized both by China-nexus espionage clusters — publicly tracked as UNC5221, UNC5174, and CL-STA-0048 — and by cybercrime groups including BianLian and RansomExx. Critical SAP flaws attract both categories of attacker.
What users and organizations should do
For macOS:
- Update now to macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9 (or later).
- Disable Screen Sharing where it is not needed: System Settings → General → Sharing → Screen Sharing. This is the effective interim mitigation if you cannot patch immediately.
- Block port 5900 at the perimeter. No Mac remote desktop service should be directly internet-facing. Require a VPN or a bastion host.
- Do not rely on password changes. Rotating the Screen Sharing or VNC password does not mitigate this flaw.
- Hunt for compromise on exposed systems. Look for unexpected high CPU usage, unfamiliar processes and LaunchDaemons, new root-level persistence, outbound connections to mining pools, and inbound connections to 5900 predating the patch. Patching does not evict an attacker who is already resident.
- Verify the fleet, don't assume it. Confirm actual installed build numbers through your MDM rather than trusting that automatic updates completed.
For SAP Commerce Cloud:
- Apply Security Note 3771065 and upgrade to 2211.55, 2211-jdk21.17, or a later supported release.
- Rebuild and redeploy. Downloading a corrected package is not remediation. The updated application must be deployed, and teams should verify the version actually running in production and in staging and test environments.
- Use an IP Filter Set as a temporary control where an upgrade needs more planning, restricting the Data Hub Adapter import endpoint to trusted Data Hub systems only.
- Prioritize externally reachable instances first, then work inward.
- Review logs for suspicious requests to the Data Hub Adapter import endpoint dating back to at least 11 August, along with any unexpected process execution, new files, or outbound connections from application servers.
For both, and for the next one:
- Treat CVSS 10.0 and confirmed in-the-wild exploitation as triggers for emergency change procedures, not the normal patch queue.
- Maintain an accurate inventory of what is exposed to the internet. Both of these stories are, at bottom, exposure stories.
- Re-check severity ratings on flaws you have already triaged. Scores move.
Final thoughts
The most useful takeaway from these two incidents has little to do with Apple or SAP specifically.
Neither of these was a zero-day. Both were patched before anyone observed them being exploited. The vendors did their part on the timeline defenders always ask for — and attackers still won on several networks, purely because publishing a fix and applying a fix are separated by days of organizational process.
That gap is now the attack surface. A published advisory is a roadmap, and it becomes public the moment the patch does. For internet-facing systems, "we'll get it in the next maintenance window" is no longer a neutral decision — it is a calculated risk with a measurable half-life.
Assume the exploitation clock starts when the patch ships, not when the exploit appears.
