Patched, Exploited Anyway: SAP and the Mac Estate
Deployment closes the vulnerability; only pre-patch access logs answer whether you were already hit — and on most Mac fleets those logs were never collected at all.
Patch status is not an incident answer
Deploying the fix for CVE-2026-58231 closes the hole. It says nothing about the interval between the patch shipping and the next change window opening. The Hacker News reports attackers were firing into exactly that interval. A vulnerability scanner will not answer the question. Web and application access logs for the pre-patch period will, on every internet-facing Commerce Cloud instance: the /hac and /backoffice administrative paths, and the OCC API endpoints. Pull them before retention rotates them out. On a commerce platform those paths sit adjacent to payment and PII flows. A regulator or an acquirer will eventually ask for that reconstruction.
Public and inferred, kept separate: the published advisory withheld the flaw class. A CVSS 10.0 on an internet-facing commerce platform almost always means unauthenticated remote code execution. That is inference, not a stated fact. Confirm against SAP's own security note before any detection logic depends on the mechanism.
The Mac estate is where inventory fails
The second exploitation is less severe and more embarrassing. The Netherlands NCSC warns that a patched macOS Screen Sharing flaw is being used against internet-exposed Macs to install Monero miners. The abused component is a legitimate operating-system feature, which makes this a perimeter and configuration problem rather than a malware problem. Two asset classes carry it in most technology companies: developer Macs on network segments with generous inbound rules, and hosted Mac build runners used for iOS CI, which routinely sit outside both EDR deployment and attack-surface-management inventory. Cryptojacking is the payload. The same access is a beachhead in a build pipeline later. That is the part that sets priority.
| Exposure | What to check | First evidence to pull | Blocking control |
|---|---|---|---|
| SAP Commerce Cloud CVE-2026-58231 | /hac, /backoffice, OCC API reachability | Pre-patch access logs for those paths | Patch, or WAF virtual patch plus IP allowlist |
| macOS Screen Sharing to Monero miner | TCP 5900, TCP/UDP 3283 on external ranges, VPCs, build fleets | Sustained CPU, stratum-protocol egress, unexpected ~/Library/LaunchAgents entries | Perimeter block plus MDM profile disabling Screen Sharing and Remote Management |
Where the reporting agrees
CSO First Look argues for re-baselining patch and exposure SLAs on internet-facing and identity-adjacent assets, and for moving spend away from faster manual triage toward exposure reduction and automated isolation. The Hacker News lands on the operational version of the same conclusion: a pre-authorized emergency lane with a 72-hour SLA for CVSS 9.0-plus internet-facing assets. The agreement matters because it isolates the constraint. Neither exploited flaw needed a novel control to survive contact. Both needed someone empowered to approve a same-day change. Shops that clear inside 72 hours held. Monthly-window shops will lose the same race with a different CVE number.
Both exploited flaws already had patches; what decided the outcome was who could approve a change inside 72 hours.
What to do
Inventory every SAP Commerce Cloud instance today, apply the CVE-2026-58231 fix or deploy WAF virtual-patch rules with IP allowlisting on /hac, /backoffice and the OCC API, and export pre-patch access logs for those paths before retention expires.
Sweep external ranges, cloud VPCs and hosted Mac build fleets for TCP 5900 and TCP/UDP 3283 within 48 hours, block at the perimeter, and disable Screen Sharing and Remote Management by MDM profile.
Stand up a pre-authorized emergency remediation lane with a 72-hour SLA for CVSS 9.0-plus internet-facing assets before the next monthly patch cycle closes.