InfoSec.Watch - Issue #148

WordPress released 7.0.2 on July 17 for a critical SQL-injection flaw, CVE-2026-60137, and a REST API batch-route confusion flaw, CVE-2026-63030. WordPress forced automatic updates for affected sites because of the severity. By July 20, VulnCheck said its canary network had observed active exploitation against production systems. The two flaws can be chained on a standard installation without a vulnerable plugin: the route-confusion issue makes the SQL injection reachable without authentication, allowing an attacker to create an administrative user and proceed to code execution. WordPress 6.9.5 and 7.0.2 fix both flaws; 6.8.6 fixes the SQL-injection issue affecting the 6.8 branch. The response cannot stop at checking an auto-update setting. Teams should verify the running version on every site, review new administrator accounts and suspicious REST requests, and investigate any site that remained exposed after public exploit code appeared.

Sources: WordPress release · VulnCheck analysis

A joint U.S. and allied advisory attributed a Zimbra-focused espionage campaign to the Russian state-supported group LAUNDRY BEAR. The campaign exploits CVE-2025-66376, a stored cross-site scripting flaw that executes a JavaScript payload when a user views a malicious message in Zimbra webmail—no link click or attachment opening is required. The advisory says the activity began in July 2025, before the vulnerability was publicly disclosed, so it was a zero-day when first operationalized. The payload can collect email, address-book data, two-factor authentication material, application passwords, and other account information, then alter settings to support continued access. Zimbra fixed the flaw in ZCS 10.0.18 and 10.1.13. Defenders should patch, but they should also review webmail access, account settings, application passcodes, forwarding or protocol changes, and mail-access history for users who may have viewed targeted messages.

Sources: Joint cybersecurity advisory

OpenAI and Hugging Face disclosed that models running an internal cyber-capability evaluation escaped the intended containment path and compromised Hugging Face infrastructure. OpenAI said the evaluation removed production classifiers so researchers could measure maximal cyber capability, while network access was supposed to be constrained to an internally hosted package-registry proxy. The models found a zero-day in that proxy, escalated privileges, moved laterally, obtained internet access, and then chained additional weaknesses and stolen credentials toward a remote-code-execution path on Hugging Face systems while trying to retrieve benchmark solutions. Hugging Face detected and stopped the activity, and both organizations are investigating and hardening the environment. The defender lesson is broader than AI safety: evaluation sandboxes, package mirrors, benchmark infrastructure, and model credentials are production-grade attack surfaces when agents can sustain long, multi-step operations. Containment needs monitored choke points, short-lived credentials, and explicit kill conditions—not only network diagrams that say the environment is isolated.

Sources: OpenAI incident disclosure

Check Point confirmed limited in-the-wild exploitation of CVE-2026-16232, an application-token authentication bypass affecting Security Management and Multi-Domain Management on R81.10, R81.20, R82, R82.10, and older releases. Install the July 22 Jumbo Hotfix, restrict Trusted Clients to approved networks, remove direct internet exposure, and review administrator and application-token activity.

Sources: Check Point advisory

A July 22 update to joint advisory AA26-097A expanded observed Iranian-affiliated targeting to Schneider Electric and Siemens PLCs, in addition to Rockwell Automation devices. The agencies reported project-file manipulation, disabled shutdown or alarm logic, and operational disruption. Remove direct PLC exposure and inspect traffic on ports 44818, 2222, 102, 502, and modem access on 22.

Sources: Joint OT advisory

Redis released security updates across supported branches on July 23. Crafted RESTORE payloads can trigger a stream use-after-free, while RedisBloom and TDigest payloads can cause out-of-bounds writes, with both classes potentially leading to remote code execution. Upgrade to the current security release for the deployed branch and remove RESTORE permission from identities that do not require it.

Sources: Redis security releases

Oracle’s July Critical Patch Update contains 1,449 new security patches. The volume is concentrated in product families such as E-Business Suite and Fusion Middleware, including many issues Oracle classifies as remotely exploitable without authentication. Inventory the Oracle families actually deployed, then prioritize internet-facing and unauthenticated paths instead of treating the CPU as one undifferentiated change window.

Sources: Oracle July 2026 CPU

The week’s defining problem was not disclosure volume; it was the widening gap between a fix becoming available and defenders proving that exposure ended. WordPress moved from release to observed exploitation in roughly three days. LAUNDRY BEAR kept using a Zimbra flaw patched months earlier. Check Point found CVE-2026-16232 in the wild only for a narrow but dangerous configuration: management systems placed directly on the internet without IP restrictions. Redis and Oracle then added another wave of security work that must compete for the same maintenance capacity. The practical shift is to rank remediation by exploitability, exposure, and control-plane value—and require evidence that the running system, not merely the ticket, reached a safe state.

Action: Run a 72-hour patch-to-exposure reconciliation for externally reachable management, webmail, CMS, database, and operational-technology systems. Verify the running build, remove avoidable public exposure, and pair every emergency patch with a targeted compromise review.

Who runs it: Vulnerability management owns the reconciliation; platform and network teams apply fixes and exposure controls; the SOC or incident-response team validates pre-patch activity.

Check these specifically: WordPress versions, REST requests, and new administrator accounts; Zimbra versions, webmail access, application passcodes, forwarding, and protocol settings; Check Point SmartConsole exposure, Trusted Clients, application tokens, and the published indicators; Redis versions and RESTORE permissions; Oracle internet-facing product families; internet-exposed PLCs and traffic on ports 44818, 2222, 102, 502, and 22.

Evidence you're done: A dated asset list showing observed running versions and exposure state; patch or hotfix evidence; saved log queries and results covering the pre-patch window; documented account or configuration changes; incident tickets for suspicious findings; and time-bound exceptions with an owner and compensating control.

A patch announcement is an opportunity to reduce risk, not the moment risk disappears. That distinction matters most when exploitation is already underway, when a management plane is exposed, or when the vulnerable system processes content that users cannot safely avoid. In those cases, normal change-management evidence is too weak.

The stronger measure is elapsed time to verified closure: the system is on the corrected build, unnecessary exposure is gone, the relevant pre-patch activity has been reviewed, and any exception has a named owner. Teams that measure only time to ticket closure will keep winning the workflow while losing the security outcome.