FOCUS FRIDAY: TPRM Insights on Critical Vulnerabilities in WordPress, NGINX, SolarWinds Serv-U, Oracle WebLogic, Zimbra, Exim, RabbitMQ, Langflow, Gitea, SharePoint

Introduction

This week's Focus Friday spans nine FocusTags® covering a threat landscape that reaches from unauthenticated WordPress core RCE chained across millions of public-facing websites, to critical-severity zero-day and CISA KEV-listed vulnerabilities in AI workflow infrastructure, message broker authentication bypass, and Oracle's largest single-week WebLogic patch batch in recent history. The diversity of platforms — web servers, managed file transfer, application servers, message brokers, mail infrastructure, and developer tooling — reflects the distributed nature of enterprise vendor technology stacks and the growing challenge of tracking vulnerability exposure across all layers of that stack.

The week's most operationally urgent active exploitation event is CVE-2026-0770 in Langflow, the open-source AI workflow orchestration platform: a CVSS 9.8 unsafe code execution vulnerability with EPSS 10.37%, a public PoC, and CISA KEV listing. The default Langflow configuration (AUTO_LOGIN=true) effectively eliminates authentication as a barrier on most deployed instances, making unauthenticated remote code execution the realistic exploitation outcome for any internet-accessible Langflow instance still running a version at or below 1.7.3. The WordPress wp2shell chain (CVE-2026-63030 + CVE-2026-60137) provides the week's broadest exposure surface: a two-CVE unauthenticated RCE chain in WordPress core — no plugins required — with a public PoC published July 18 and early exploitation activity already observed across the massive population of internet-facing WordPress sites.

Oracle WebLogic's July 2026 Critical Patch Update carries eleven vulnerabilities in a single Core component, nine of them fully unauthenticated with CVSS scores of 9.1 to 9.9, exploitable across HTTP, T3, IIOP, SOAP, and SAML — a breadth that makes protocol-level filtering alone an insufficient control. SolarWinds Serv-U 2026.3 addresses sixteen vulnerabilities across its managed file transfer platform, fifteen of them rated CRITICAL at CVSS 9.1, in the platform category that has historically drawn the most sustained threat actor attention in the third-party breach ecosystem. NGINX's three memory-safety flaws extend well beyond the core reverse proxy into Kubernetes-native, API gateway, and cloud security infrastructure. RabbitMQ discloses four authentication and authorization flaws spanning TLS client authentication bypass, JWT forgery, and OAuth client secret exposure — a message broker compromise that reaches directly into every application and microservice pipeline connected to the broker.

Filtered view of vendors with WordPress - wp2shell FocusTag® on the Black Kite platform.

WordPress - wp2shell (CVE-2026-63030, CVE-2026-60137)

What is this vulnerability?

The wp2shell vulnerability chain combines two separately tracked flaws in WordPress core to achieve unauthenticated Remote Code Execution on a default WordPress installation — with no plugins, no valid user account, and no user interaction required. CVE-2026-63030 (CVSS 9.8, CWE-436) is a REST API batch-route confusion weakness in WP_REST_Server::serve_batch_request_v1(), reachable via the /wp-json/batch/v1 endpoint that has shipped with WordPress since version 5.6. On its own, the route confusion is a bounded problem. CVE-2026-60137 (CVSS 9.1, CWE-89) is a SQL injection in the author__not_in parameter of WP_Query, the core class that builds most WordPress database queries. On its own, it is a data-integrity issue that surfaces when a plugin or theme passes untrusted input to the parameter. On WordPress 6.9 and later, the two flaws combine: the batch endpoint provides unauthenticated network reach, the SQL injection provides the code execution path, and the result is pre-authentication RCE on any internet-facing WordPress instance running a vulnerable core version in default configuration.

The full RCE chain affects WordPress core 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. WordPress 6.8.0 through 6.8.5 carries only the SQL injection component (CVE-2026-60137) and is not exposed to the full wp2shell RCE chain, but still requires patching to 6.8.6. Versions prior to 6.8.0 are not affected. A working proof-of-concept describing the full exploitation mechanism was published on July 18, 2026, discovered and responsibly disclosed by Adam Kues (Assetnote / Searchlight Cyber) for CVE-2026-63030, and by TF1T, dtro, and haongo for CVE-2026-60137. WordPress released patched versions 6.8.6, 6.9.5, and 7.0.2 on July 17, 2026, and force-pushed automatic updates to affected sites where auto-update was enabled. Early signs of in-the-wild exploitation have been reported by multiple vendors since the PoC publication. Approximately 2,413 externally exposed WordPress instances running affected versions (6.8.x through 7.0.1) are currently detectable on Shodan.

Why should TPRM professionals care?

WordPress powers a substantial share of the world's public-facing websites, and this chain lives entirely in core — independent of any third-party plugin or theme. The vulnerable population is therefore not concentrated in a specific plugin category: any internet-facing WordPress site on core version 6.8.0 or later and below the patched releases is potentially exposed. Enterprise vendor ecosystems routinely include secondary WordPress properties — campaign sites, regional brand properties, product microsites, and subsidiary web presences — that receive less patching attention than flagship domains. These decentralized WordPress installations are precisely the class of assets most likely to still be running vulnerable core versions post-disclosure. With early exploitation activity already observed and a public PoC lowering the skill barrier, TPRM professionals cannot treat this as a low-priority future event: any vendor with internet-facing WordPress sites that has not confirmed patched core versions should be treated as actively at risk.

What questions should TPRM professionals ask vendors?

1.  Has WordPress core been updated to version 6.8.6 (6.8.x sites), 6.9.5 (6.9.x sites), or 7.0.2 (7.0.x sites) across all internet-facing WordPress properties — including secondary brand sites, campaign microsites, regional properties, and subsidiary domains? Do you maintain a complete inventory of all internet-facing WordPress instances?

2.  Did WordPress's forced automatic update mechanism successfully apply patches to all eligible WordPress sites? Auto-updates can fail or be disabled; manual verification of the installed core version on each site is required rather than assuming the forced update completed.

3.  For sites on WordPress 6.8.0 through 6.8.5: these carry CVE-2026-60137 (SQL injection) even without the full RCE chain — has the 6.8.6 patch been applied to all sites in this version range?

4.  Has the /wp-json/batch/v1 endpoint been restricted at the WAF or reverse proxy layer on any sites not yet confirmed as patched? Blocking or rate-limiting this endpoint mitigates the CVE-2026-63030 attack entry point for the RCE chain.

5.  Have REST API logs and server access logs been reviewed on WordPress sites that ran vulnerable versions during the July 18–July 24 window for unexpected batch requests, SQL injection patterns, or anomalous POST activity to /wp-json/ endpoints?

Remediation recommendations

• Update WordPress core to 6.8.6, 6.9.5, or 7.0.2 immediately on all internet-facing properties. Do not rely on automatic update confirmation alone — verify the installed core version directly on each site's WordPress admin panel or via WP-CLI.
• Audit all internet-facing WordPress instances across the full vendor asset inventory, including secondary, subsidiary, and campaign properties that may have less centralized management. WordPress version scanning tools (WPScan, built-in monitoring) can enumerate installed versions across a multi-site portfolio.
• Restrict or block access to the /wp-json/batch/v1 endpoint at the WAF or web application firewall layer on any sites where immediate patching is not confirmed. This reduces the attack surface for CVE-2026-63030's batch-route confusion entry point.
• Review server and application logs for evidence of exploitation on any site that ran vulnerable WordPress core versions (6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0–7.0.1) while internet-accessible after July 18, 2026. Unexpected administrator account creation, modified core files, or new file uploads are indicators of a successful compromise.
• Apply updates to WordPress 7.1 beta2 or later for any pre-release 7.1 branch deployments, which are also affected by both CVEs.

Black Kite's WordPress - wp2shell FocusTag® details critical insights on the event for TPRM professionals.

NGINX - Jul2026 (CVE-2026-42533)

What is this vulnerability?

F5 has patched three memory-safety vulnerabilities in NGINX Plus and NGINX Open Source: CVE-2026-42533 (CVSSv4 9.2), CVE-2026-60005 (CVSSv4 8.8), and CVE-2026-56434 (CVSSv4 8.3). All three flaws reside in the data plane and are reachable by unauthenticated attackers via crafted HTTP requests. No confirmed in-the-wild exploitation or public proof-of-concept has been reported.

CVE-2026-42533 is a heap-based buffer overflow in the Map directive's regex matching logic. It triggers when a map directive uses regex matching and a string expression references the map's regex capture variables before the map output variable — a nuanced but reachable configuration pattern in production deployments. Crafted requests cause a heap buffer overflow in the NGINX worker process: the default outcome is a worker crash and restart, but when ASLR is disabled or successfully bypassed — a realistic condition in containerized environments, embedded appliances, or misconfigured systems — the flaw escalates to full Remote Code Execution. CVE-2026-60005 is an uninitialized memory access in the ngx_http_slice_module (off by default), triggered when the slice directive runs with unnamed regex captures or during background cache updates. It may result in limited memory disclosure or a worker restart. CVE-2026-56434 is a use-after-free in the SSI module requiring Server-Side Includes, proxy_pass, and proxy_buffering off in combination with a man-in-the-middle position over upstream proxy responses, enabling limited memory modification or a worker restart.

All three flaws extend beyond core NGINX into downstream products: NGINX App Protect WAF 4.x/5.x, NGINX Gateway Fabric 1.x/2.x, NGINX Ingress Controller, NGINX Instance Manager 2.17.0–2.22.1, and F5 WAF for NGINX 5.9.0–5.13.3 are all affected. Fixed releases: NGINX Open Source 1.31.3 and 1.30.4; NGINX Plus R36 P7 and 37.0.3.1; NGINX Gateway Fabric 2.6.7; NGINX Ingress Controller 5.5.3 and 2026-lts-r4. An interim configuration workaround is available for CVE-2026-42533 and CVE-2026-60005: replace unnamed regex captures with named captures and reference them only inside the block that holds the regex match.

Why should TPRM professionals care?

NGINX is one of the world's most widely deployed reverse proxies and web servers, handling the majority of internet-facing web traffic for a significant share of enterprise vendor environments. CVE-2026-42533's RCE potential under ASLR-absent conditions is particularly relevant in containerized deployment contexts where ASLR enforcement varies across container runtimes and base images. The extension of all three flaws into NGINX App Protect WAF, NGINX Gateway Fabric, and NGINX Ingress Controller significantly amplifies the affected footprint: organizations that have deployed NGINX as a security control layer or Kubernetes ingress controller are exposed at a higher infrastructure criticality than a standalone web server. Approximately 553,600 NGINX-related internet-facing instances are detectable on Shodan across affected versions and downstream products.

What questions should TPRM professionals ask vendors?

1.  Have NGINX Open Source instances been upgraded to 1.31.3 or 1.30.4, and NGINX Plus instances to R36 P7 or 37.0.3.1 — the specific releases addressing CVE-2026-42533, CVE-2026-60005, and CVE-2026-56434?

2.  Are downstream NGINX products in use — including NGINX App Protect WAF, NGINX Gateway Fabric, NGINX Ingress Controller, NGINX Instance Manager, or F5 WAF for NGINX? If so, have these been updated to NGINX Gateway Fabric 2.6.7, NGINX Ingress Controller 5.5.3 / 2026-lts-r4, and the corresponding Instance Manager and App Protect releases?

3.  For CVE-2026-42533: is ASLR explicitly enforced on all systems running NGINX? In containerized NGINX deployments, what container runtime and base image configuration is used, and is kernel-level ASLR confirmed active?

4.  If immediate patching is not possible: has the interim configuration workaround been applied — replacing unnamed regex captures with named captures in all NGINX map directives, to mitigate the heap overflow trigger condition?

5.  For CVE-2026-56434 (MitM use-after-free): does any NGINX deployment proxy to upstream services over untrusted or third-party-controlled networks? This constrains the realistic attack vector but is relevant for NGINX deployments acting as reverse proxies to external upstream APIs.

Remediation recommendations

• Upgrade NGINX Open Source to 1.31.3 or 1.30.4, and NGINX Plus to 37.0.3.1 or R36 P7 immediately. Patch all downstream products: NGINX Gateway Fabric to 2.6.7, NGINX Ingress Controller to 5.5.3 or 2026-lts-r4.
• If immediate patching is not feasible, apply the F5-recommended configuration workaround: replace unnamed regex captures with named captures in all map directives, and reference them only inside the regex-matching block. This mitigates both CVE-2026-42533 and CVE-2026-60005 at the configuration level.
• Audit NGINX deployments to identify all downstream product instances (App Protect WAF, Gateway Fabric, Ingress Controller, Instance Manager, F5 WAF for NGINX) — these are often managed separately from core NGINX and may have independent patch cadences.
• Verify ASLR enforcement across all NGINX deployment contexts, including containerized environments. Enable kernel-level ASLR (sysctl kernel.randomize_va_space=2) on any host running NGINX where it may not be enforced.

Black Kite's NGINX - Jul2026 FocusTag® details critical insights on the event for TPRM professionals.

SolarWinds Serv-U - Jul2026 (CVE-2026-28302, CVE-2026-28304, CVE-2026-28305, CVE-2026-28306, CVE-2026-28307, CVE-2026-28308, CVE-2026-28309, CVE-2026-28310, CVE-2026-28311, CVE-2026-28312, CVE-2026-28313, CVE-2026-28314, CVE-2026-28315, CVE-2026-28316, CVE-2026-28317, CVE-2026-28321)

What is this vulnerability?

SolarWinds released Serv-U 2026.3 on July 21, 2026, addressing 16 vulnerabilities in Serv-U MFT (Managed File Transfer) and Serv-U FTP Server, all reported through the Intigriti Bug Bounty Program. Fifteen of these vulnerabilities are rated CRITICAL at CVSS 9.1, spanning Insecure Direct Object Reference (IDOR), Privilege Escalation, Remote Code Execution, and Broken Access Control classes. All critical CVEs affect Serv-U versions across the entire historical release line (2.x through 15.5.4 HF1) and are fixed exclusively in Serv-U 2026.3. CVE-2026-28315 is the sole non-critical finding — a Stored XSS rated CVSS 6.2 that can lead to session hijacking or information disclosure from an administrator account.

The critical vulnerabilities span several distinct exploitation classes. CVE-2026-28302 and CVE-2026-28305 are IDOR flaws that escalate group administrator and domain admin access respectively to root code execution on Linux. CVE-2026-28304 enables remote code execution as root without administrative precondition details specified. CVE-2026-28306, CVE-2026-28307, CVE-2026-28309, CVE-2026-28310, CVE-2026-28312, and CVE-2026-28316/28317 are privilege escalation vulnerabilities that elevate domain administrators or group administrators to system administrator or root-level execution. CVE-2026-28308 is an IDOR enabling RCE from domain admin access. CVE-2026-28313 is an IDOR enabling SMTP hijacking leading to arbitrary account takeover (domain admin required). CVE-2026-28314 is the most accessible critical vulnerability — it requires only standard user authentication and enables arbitrary account takeover via IDOR. CVE-2026-28321 enables arbitrary file read and write leading to privilege escalation and root code execution from domain admin. On Windows deployments, impact is lower across the critical CVE set. No public PoC and no CISA KEV listing at time of publication.

Why should TPRM professionals care?

SolarWinds Serv-U belongs to the managed file transfer platform category — the sector most disproportionately represented in major third-party breach events of the past several years, with MOVEit (2023), Cleo Harmony (2024), and GoAnywhere (2025) establishing a clear threat actor pattern of large-scale exploitation targeting MFT platforms specifically because of their position as cross-organizational file exchange hubs holding sensitive business data. SolarWinds Serv-U has its own prior exploitation history — including Clop ransomware group targeting. Fifteen CRITICAL vulnerabilities in a single batch, several of which escalate from administrative credentials to root OS-level execution, represent a significant attack surface expansion at a moment when MFT platforms remain actively hunted. CVE-2026-28314's standard-user-to-account-takeover path is particularly concerning as it does not require elevated Serv-U privileges to initiate exploitation.

What questions should TPRM professionals ask vendors?

1.  Has SolarWinds Serv-U been upgraded to version 2026.3 — the only release that addresses all 16 CVEs disclosed in July 2026? What Serv-U version is confirmed installed across all Serv-U MFT and FTP Server deployments?

2.  Is Serv-U deployed on Linux? The most severe impacts for the critical CVE set — particularly root code execution — apply to Linux deployments. Windows deployments have lower stated impact; understanding the OS context informs prioritization.

3.  Which administrative account types are in use on Serv-U deployments — domain administrator, group administrator, system administrator? Given that most critical CVEs require domain or group admin credentials, what controls govern access to these account types (MFA, IP restriction, audit logging)?

4.  For CVE-2026-28314 (standard user authentication required → account takeover): have Serv-U user accounts been audited for unexpected account modifications or unauthorized access that may indicate exploitation during the pre-patch exposure window?

5.  Is the Serv-U management interface internet-accessible, or restricted to internal networks? Given the privilege escalation chain from domain admin to root, access restriction on the Serv-U administrative interface is a critical compensating control pending patching.

Remediation recommendations

• Upgrade to Serv-U 2026.3 immediately — this is the only release addressing all 16 CVEs. The full historical release line (2.x through 15.5.4 HF1) is affected; there are no CVE-specific patches for older releases.
• On Linux Serv-U deployments, treat patching as highest priority: the CVSS 9.1 critical CVEs specify lower impact on Windows but full root execution on Linux. Confirm OS platform for all Serv-U instances and prioritize accordingly.
• Restrict Serv-U administrative interface access to internal networks and trusted IP ranges. Revoke or rotate domain administrator and group administrator credentials as a precautionary measure following the patch, given the exposure window against the IDOR-to-root escalation chains.
• Audit Serv-U user account activity logs — particularly for CVE-2026-28314 (standard user → account takeover) — for anomalous account modifications, unexpected login activity, or file access patterns during the pre-patch window.
• Disable or restrict SMTP notification functionality in Serv-U if not required operationally, as CVE-2026-28313 leverages SMTP hijacking from domain admin access to achieve arbitrary account takeover.

Black Kite's SolarWinds Serv-U - Jul2026 FocusTag® details critical insights on the event for TPRM professionals.

Oracle WebLogic - Jul2026 (CVE-2026-60206, CVE-2026-60205, CVE-2026-60204, CVE-2026-60202, CVE-2026-60198, CVE-2026-60294, CVE-2026-60200, CVE-2026-60291, CVE-2026-60292, CVE-2026-60199, CVE-2026-60208)

What is this vulnerability?

Oracle's July 2026 Critical Patch Update discloses eleven vulnerabilities in the Core component of Oracle WebLogic Server — all rated CRITICAL with CVSSv3 scores from 9.1 to 9.9. Nine of the eleven require no authentication. The vulnerabilities are exploitable across five distinct network protocols: HTTP, T3, IIOP, SOAP, and SAML. Affected versions are WebLogic Server 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0, and 15.1.1.0.0, with specific version coverage varying by CVE. No public PoC and no confirmed in-the-wild exploitation at time of publication. Fix: July 2026 CPU patches from Oracle's security alert advisory.

CVE-2026-60206 (CVSS 9.9, EPSS 0.48%) is the defining flaw: while it requires low privileges rather than no authentication, its Changed Scope CVSS indicator means successful exploitation can cascade beyond the WebLogic Server instance itself — compromising connected products, databases, and adjacent middleware in the same infrastructure. Eight vulnerabilities at CVSS 9.8 (EPSS 0.52% each) — CVE-2026-60205, CVE-2026-60204, CVE-2026-60202, CVE-2026-60198, CVE-2026-60294, CVE-2026-60200, CVE-2026-60291, CVE-2026-60292, CVE-2026-60199 — require no authentication and yield complete server takeover. CVE-2026-60208 (CVSS 9.1, EPSS 0.43%) enables an unauthenticated attacker to create, delete, or modify critical data and achieve full read access to all WebLogic-accessible data over HTTP without achieving full server takeover.

Why should TPRM professionals care?

Oracle WebLogic Server is the core Java EE application server underpinning ERP systems, financial transaction platforms, government portals, and enterprise middleware stacks across large organizations. The combination of eleven CRITICAL vulnerabilities concentrated in a single Core component, nine of them unauthenticated, exploitable across five protocols, represents one of the most severe Oracle WebLogic patch events in recent history. The five-protocol attack surface means that restricting a single protocol (e.g., blocking T3) is insufficient: HTTP, IIOP, SOAP, and SAML remain viable attack paths. CVE-2026-60206's Changed Scope indicator is the highest-urgency signal for TPRM: a compromise of one WebLogic instance can propagate impact into connected enterprise systems, meaning WebLogic exploitation is a potential entry point for broader organizational compromise.

What questions should TPRM professionals ask vendors?

1.  Has the July 2026 Oracle Critical Patch Update been applied to all Oracle WebLogic Server instances across versions 12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0, and 15.1.1.0.0? Oracle CPU patches must be applied per-version as coverage varies by CVE.

2.  Are WebLogic Server T3, IIOP, and administrative ports restricted to trusted internal networks, or are they internet-accessible? Given that the eleven CVEs are exploitable across HTTP, T3, IIOP, SOAP, and SAML, access restriction to internal networks is a critical compensating control for unpatched instances.

3.  For CVE-2026-60206 (Changed Scope, low privilege): what systems and databases are connected to or accessible from the WebLogic Server instances? The Changed Scope indicator means successful exploitation can affect resources beyond WebLogic itself — understanding the blast radius of a WebLogic compromise is essential.

4.  Is WebLogic Server placed behind a firewall with explicit rules blocking untrusted network traffic to the application server ports? Both T3 and IIOP are high-value Oracle-specific protocols that should be inaccessible from untrusted networks.

5.  What is the patch deployment timeline for the July 2026 CPU? Oracle CPU patches can require testing periods before production deployment; what compensating controls are in place during the patching window for internet-accessible WebLogic instances?

Remediation recommendations

• Apply the July 2026 Oracle Critical Patch Update for all affected WebLogic Server versions without delay. Consult the Oracle CPU advisory at oracle.com/security-alerts/cpujul2026.html for the specific patch identifiers per version (12.2.1.4.0, 14.1.1.0.0, 14.1.2.0.0, 15.1.1.0.0).
• Immediately restrict T3, IIOP, and administrative port access to trusted internal IP ranges as a compensating control during the patch deployment window. These protocols should not be accessible from untrusted networks regardless of patch status.
• Place all WebLogic Server instances behind a firewall with explicit rules denying untrusted network access to application server ports. HTTP-exposed WebLogic endpoints should be fronted by a reverse proxy or load balancer that applies WAF inspection.
• Map all systems, databases, and middleware connected to or accessible from each WebLogic instance — both to understand the blast radius of CVE-2026-60206's Changed Scope exploitation and to prioritize patching for instances with the broadest downstream access.

Black Kite's Oracle WebLogic - Jul2026 FocusTag® details critical insights on the event for TPRM professionals.

Zimbra - Jul2026

What is this vulnerability?

Zimbra Collaboration Suite 10.1.20, released July 20, 2026, delivers a permanent fix for a command injection vulnerability in ZCS's SNMP monitoring component — first disclosed via Zimbra security advisory on June 26, 2026, for which only temporary mitigations were previously available. The SNMP vulnerability triggers when SNMP notifications are enabled: crafted input can cause the SNMP component to execute arbitrary OS commands on the host running the Zimbra server. An estimated CVSSv3 score of 8.8 is attributed to this flaw. No CVE identifier has been assigned to any of the 10.1.20 security fixes at time of publication.

The 10.1.20 release also addresses multiple additional vulnerabilities. Four stored Cross-Site Scripting flaws in the Classic Web Client are patched: malicious attachment filenames, crafted form fields, and crafted attachments can each trigger JavaScript execution when rendered in the Classic Web Client. An EWS access-control vulnerability, a mail forwarding restriction bypass enabling authenticated users to exfiltrate email despite forwarding restrictions, an SSRF flaw in the Nextcloud integration, and a mailbox delegation authorization issue are also addressed. Zimbra limits technical detail per its disclosure policy and has not published exploit code or confirmed active exploitation of any 10.1.20 fixes. All on-premises ZCS deployments running versions prior to 10.1.20 are affected. Approximately 14,309 Zimbra instances across affected 10.0.x and earlier versions are detectable on Shodan.

Why should TPRM professionals care?

Zimbra Collaboration Suite has a well-documented history as a priority target for nation-state threat actors and advanced persistent threat groups — with CVE-2022-27925, CVE-2023-37580, and CVE-2024-45519 among the prior Zimbra vulnerabilities that have been weaponized in targeted exploitation campaigns. Google's Threat Analysis Group reported the Classic Web Client XSS patched in ZCS 10.1.19 the previous week, signaling continued sophisticated adversary interest in Zimbra's attack surface. This week's SNMP command injection flaw — now receiving a permanent fix after six weeks since initial disclosure — represents OS-level code execution on the Zimbra server, the centralized hub for organizational email, calendar, contacts, and authentication context. SNMP notification functionality is a common configuration in monitored enterprise environments, meaning the SNMP command injection attack surface is realistically present across many Zimbra deployments. TPRM professionals should confirm upgrade to 10.1.20 for any vendor using Zimbra as their email infrastructure, and should check for the temporary SNMP mitigation that needed to be reapplied after the upgrade.

What questions should TPRM professionals ask vendors?

1.  Has Zimbra Collaboration Suite been upgraded to version 10.1.20 — the release delivering the permanent SNMP command injection fix and addressing the four Classic Web Client XSS vulnerabilities and additional security issues?

2.  Was the temporary SNMP mitigation (published with the June 26, 2026 security advisory) applied after upgrading to 10.1.20? Zimbra notes that the temporary mitigation must be reapplied post-upgrade if SNMP notifications are in use.

3.  Is SNMP notification functionality enabled on the Zimbra server deployment? If SNMP notifications are disabled, the SNMP command injection attack surface is not present — confirming this configuration reduces the urgency for deployments pending patching.

4.  Have ZCS Classic Web Client users been evaluated for anomalous mailbox activity — unexpected forwarding rules, unusual access patterns, or unauthorized contact exports — given the multiple Classic Web Client XSS vulnerabilities patched in 10.1.19 and 10.1.20?

5.  Are older ZCS branches (10.0.x, 9.0.x, 8.8.15) in use? These branches should be included in upgrade planning as they do not receive 10.1.x-specific patches.

Remediation recommendations

• Upgrade to ZCS 10.1.20 immediately. This is the first release delivering a permanent fix for the SNMP command injection vulnerability disclosed June 26, 2026 — prior temporary mitigations are not equivalent to the permanent patch.
• If SNMP notification functionality is enabled: reapply the SNMP temporary mitigation after completing the 10.1.20 upgrade, as Zimbra notes this step is required post-upgrade for SNMP-enabled deployments.
• Disable SNMP notification functionality in Zimbra if not required for operational monitoring. This eliminates the SNMP command injection attack surface entirely for deployments where SNMP notifications are not needed.
• Audit mailbox accounts — particularly high-privilege and high-sensitivity accounts — for anomalous forwarding rules, unexpected session access, or unauthorized mail forwarding, given the multiple Classic Web Client XSS vulnerabilities patched across 10.1.19 and 10.1.20.
• Plan upgrade paths for ZCS deployments on 10.0.x, 9.0.x, or 8.8.15 branches, as these do not receive 10.1.x security patches.

Black Kite's Zimbra - Jul2026 (Latest) FocusTag® details critical insights on the event for TPRM professionals.

Exim Mail - Jul2026 (GCVE-25-2026-07-45-1)

What is this vulnerability?

A local directory traversal vulnerability tracked as GCVE-25-2026-07-45-1 (advisory identifier EXIM-Security-2026-06-22.1) has been disclosed in Exim, one of the most widely deployed Mail Transfer Agents (MTAs) on the internet. No standard CVE identifier has been assigned; the issue uses the GCVE (Global CVE) numbering system. The Exim maintainers published the advisory on July 22, 2026; the fixed branch was pushed on July 15, 2026.

The flaw resides in Exim's queue-name handling: command-line arguments intended for transferring a queue name through an Exim execution chain can be abused to access files outside the spool area. This path traversal enables a local attacker to read or access files outside the intended spool directory, which can then be leveraged for privilege escalation. Exploitation requires command-line access on the host — this is a local attack, not remotely exploitable. Affected versions: Exim 4.88 (2017) through 4.99.4. Fixed in Exim 4.99.5. The fix restricts the relevant command-line options to already-privileged users and restricts the characters permitted for queue names. No public PoC. No confirmed in-the-wild exploitation. The Exim maintainers rate the vulnerability as HIGH severity; no numeric CVSS score has been published.

Why should TPRM professionals care?

Exim is one of the most widely deployed MTAs on the internet, with approximately 1.7 million instances detectable on Shodan — making the total installed base exceptionally large even though this specific vulnerability's local-only attack vector limits its directly exploitable surface. The local privilege escalation risk is most significant in shared hosting environments, CI/CD infrastructure, jump boxes, and multi-user systems where local user access is routinely available to multiple parties. In these contexts, the boundary between local access and Exim's operational privileges becomes a meaningful lateral movement path. Exim's historical vulnerability profile includes several remotely exploitable critical CVEs (including the Exim21 chain), which have made it a priority target for automated scanning and exploitation. Any new Exim vulnerability, even with a local attack vector, warrants patching given the platform's exploitation history and the scale of its deployment.

What questions should TPRM professionals ask vendors?

1.  Has Exim been upgraded to version 4.99.5 — the release addressing GCVE-25-2026-07-45-1 (EXIM-Security-2026-06-22.1)? What Exim version is confirmed installed on all mail infrastructure?

2.  On systems running Exim, do multiple users or service accounts have command-line access? The directory traversal vulnerability requires local command-line access; the presence of multi-user environments or shared hosting contexts elevates the exploitability of this local flaw.

3.  Is Exim deployed on shared hosting infrastructure, CI/CD runners, or jump boxes where local access is granted to multiple parties or external-facing processes? These environments represent the highest-risk deployment contexts for a local privilege escalation in the MTA.

4.  Are other Exim security patches current? Exim 4.99.x is the supported branch. Are older Exim versions deployed in the environment that may also carry unpatched historical vulnerabilities?

Remediation recommendations

• Upgrade Exim to version 4.99.5 immediately. This is the only release addressing GCVE-25-2026-07-45-1. The fix restricts queue-name command-line arguments to already-privileged users and limits permissible characters.
• Apply principle of least privilege to all accounts with shell access on Exim servers. Limit command-line access to accounts that operationally require it, reducing the population of users who could trigger the queue-name traversal path.
• On shared hosting, CI/CD, or multi-user systems running Exim: audit user access policies and consider whether Exim's process account requires any hardening (dedicated user, filesystem permission restrictions on the spool area) to limit the impact of a successful traversal.
• Monitor the Exim security advisory page (exim.org) for additional patches. The Exim 4.99.x branch is actively maintained and the canonical source for security fixes.

Black Kite's Exim Mail - Jul2026 FocusTag® details critical insights on the event for TPRM professionals.

RabbitMQ (GHSA-cw8c-4m83-9c6w, GHSA-37wx-r6q9-6fhj)

What is this vulnerability?

Four authentication and authorization vulnerabilities affecting RabbitMQ Server have been disclosed and patched in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. All four were present in the codebase since early 2024. No CISA KEV listing and no confirmed active exploitation at time of publication. The two internally discovered flaws — the TLS client-authentication bypass and the OAuth2 JWKS bypass — are tracked solely under GHSA identifiers (GHSA-cw8c-4m83-9c6w and GHSA-37wx-r6q9-6fhj) with no CVE identifiers assigned. The two remaining flaws are referenced as CVE-2026-57219 and CVE-2026-57221 in third-party security reporting; however, these CVE records had not been formally published in NVD or MITRE at time of publication.

The trust-store TLS client-authentication bypass (CVSSv4 9.1, GHSA-cw8c-4m83-9c6w) affects the rabbitmq_trust_store plugin. The plugin validates whitelisted certificates by matching only the Issuer Distinguished Name and Serial Number — fields taken verbatim from the presented certificate body, with no public-key, fingerprint, or signature comparison. An attacker who knows or can guess the {Issuer, Serial} pair of any whitelisted certificate can forge a self-signed certificate that passes the match check with their own keypair, achieving full TLS authentication bypass. The OAuth2 JWKS bypass (CVSSv4 9.2, GHSA-37wx-r6q9-6fhj) occurs when no CA bundle is configured and the OS CA bundle is empty or unreadable (e.g., in a minimal container): the OAuth2 plugin silently falls back to verify_none with no warning. An attacker in a man-in-the-middle position can forge JWKS responses, causing the broker to accept arbitrary attacker-issued JWTs.

CVE-2026-57219 (CVSS 8.7) exposes an obsolete HTTP API endpoint — GET /api/auth — whose authorization check is hard-coded to always allow the request. On RabbitMQ installations using management.oauth_client_secret, this endpoint reveals the OAuth client secret to any unauthenticated requester. The client secret can then be exchanged for an administrator token, granting full control over every message, queue, user, and broker setting. The risk is sharpest where the management port (15672) is reachable by untrusted networks. CVE-2026-57221 (CVSS 5.3) allows any authenticated user connected to a virtual host to enumerate all queue and exchange names across that virtual host and read message and consumer counts — bypassing the intended tenant isolation model.

Why should TPRM professionals care?

RabbitMQ is a foundational message broker deployed across enterprise microservice architectures, event-driven systems, and IoT data pipelines — handling sensitive inter-service communication and often holding message payloads containing business-critical or regulated data. A TLS authentication bypass in the trust-store plugin eliminates the identity verification that governs which systems can connect to the broker as authenticated clients. CVE-2026-57219's OAuth client secret exposure is directly mapped to a full broker takeover path: a single unauthenticated HTTP request to an always-permitted endpoint yields credentials for administrator-level access to every queue, exchange, and user on the broker. In multi-tenant or cloud-hosted RabbitMQ deployments, CVE-2026-57221's cross-virtual-host data exposure breaks the tenant boundary assumptions that govern data segregation.

What questions should TPRM professionals ask vendors?

1. Has RabbitMQ Server been upgraded to version 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0 — the releases addressing all four disclosed vulnerabilities? All four flaws have been present since early 2024 across 3.13.0 and later release lines.
2. Is the rabbitmq_trust_store plugin enabled and used as the TLS verify_fun? If so, has the trust-store plugin been updated as part of the server upgrade, and have whitelisted certificate entries been audited to confirm no unexpected certificates have been added?
3. Is the RabbitMQ management interface (port 15672) accessible from untrusted networks or the public internet? For CVE-2026-57219 (GET /api/auth OAuth secret exposure): access restriction to port 15672 is a critical compensating control.
4. If the management.oauth_client_secret configuration key is in use: has the OAuth client secret been rotated following the patch? Given CVE-2026-57219's trivial exploitation path via an always-permitted endpoint, any management interface that was network-accessible before patching should have its OAuth client secret rotated.
5. For the OAuth2 JWKS bypass: does any RabbitMQ deployment use the OAuth2 plugin without a configured cacertfile and with a minimal or empty OS CA bundle? Container-based RabbitMQ deployments are the most common context for this misconfiguration.

Remediation recommendations

• Upgrade RabbitMQ to 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0 immediately — these are the only releases addressing all four disclosed vulnerabilities. All four flaws have been present since early 2024.
• Rotate the OAuth client secret (management.oauth_client_secret) if the RabbitMQ management interface was accessible from any untrusted network before the patch was applied. CVE-2026-57219's exploitation requires only one HTTP request and leaves no server-side trace.
• Restrict the RabbitMQ management interface (port 15672) to trusted internal IP ranges. This eliminates the unauthenticated exploitation vector for CVE-2026-57219 and reduces the network-reachable attack surface for the TLS bypass vulnerabilities.
• For the OAuth2 JWKS bypass: ensure all RabbitMQ deployments using the OAuth2 plugin have a valid cacertfile configured. In container environments, verify that the OS CA bundle is populated and accessible to the RabbitMQ process.
• Audit virtual host permissions to enforce the principle of least privilege: CVE-2026-57221's cross-tenant queue enumeration exploits missing authorization checks on virtual host data access; separating tenants across distinct virtual hosts with properly scoped user permissions reduces blast radius.

Black Kite's RabbitMQ FocusTag® details critical insights on the event for TPRM professionals.

Langflow - Jul2026 (Latest) (CVE-2026-0770)

What is this vulnerability?

CVE-2026-0770 (CVSS 9.8, EPSS 10.37%) is a critical unsafe code execution vulnerability in Langflow, an open-source low-code platform for building and orchestrating AI workflows and agentic pipelines. The flaw is in the validate_code() function in src/lfx/src/lfx/custom/validate.py, which invokes Python's exec() on user-supplied code without any sandboxing, allowing import of arbitrary dangerous modules (os, subprocess, socket) and execution of arbitrary OS commands on the host server. The vulnerability is exploitable across five API endpoints. Two require no authentication: /api/v1/webhook/{flow_id} and /api/v1/build_public_tmp/{flow_id}/flow. The three nominally authenticated endpoints are trivially bypassed when AUTO_LOGIN=true — Langflow's default configuration — making virtually all default deployments unauthenticated targets. CVE-2026-0770 is confirmed as actively exploited and is listed in CISA's Known Exploited Vulnerabilities catalog. A public PoC is available. All Langflow versions up to and including 1.7.3 are affected.

The exploitation technique leverages Python's generator .throw() method to execute arbitrary commands via default argument evaluation at function definition time within exec() — producing output directly in the HTTP response body and enabling fully interactive RCE without any out-of-band channel. Beyond validate_code(), four additional functions in the same module (eval_function(), execute_function(), create_function(), create_class()) share the same unsafe exec() pattern, significantly expanding the attack surface. A second CVE, CVE-2026-5027, is also included in this FocusTag®; source data for this CVE was not available at publication time. EPSS 10.37% places CVE-2026-0770 in the extreme upper tier of exploitation probability, indicating active and ongoing targeting of vulnerable instances.

Why should TPRM professionals care?

Langflow is deployed as an AI workflow orchestration hub in enterprise and research environments — routinely connected to LLM APIs, vector databases, cloud credentials, and sensitive data pipelines. Full OS-level code execution on a Langflow instance therefore reaches every connected AI service, data store, and cloud credential the instance accesses. The CISA KEV listing is the definitive operational signal of real-world active exploitation. The EPSS of 10.37% indicates that a significant proportion of vulnerable instances are actively targeted. The default AUTO_LOGIN=true configuration — which eliminates authentication as a barrier on the three nominally authenticated endpoints — means that any Langflow deployment accessible from the internet and still running version 1.7.3 or below should be treated as already compromised until forensically ruled otherwise. For TPRM professionals, any vendor using Langflow for AI workflow automation is a high-urgency engagement target.

What questions should TPRM professionals ask vendors?

1.  Has Langflow been upgraded beyond version 1.7.3 — the last version confirmed vulnerable to CVE-2026-0770? What Langflow version is confirmed running, and when was the upgrade applied?

2.  Given CISA KEV listing and EPSS 10.37%: has a forensic review of Langflow server access logs been conducted for evidence of exploitation — specifically for unexpected POST requests to /api/v1/validate, /api/v1/webhook/{flow_id}, or /api/v1/build_public_tmp/ endpoints — before or during the patch window?

3.  Is Langflow internet-accessible, or restricted to internal networks and VPN-gated access? Internet-accessible Langflow instances on versions at or below 1.7.3 should be treated as highest-urgency given active exploitation.

4.  Was AUTO_LOGIN=true the configuration on Langflow deployments? This default configuration eliminates authentication on the three nominally authenticated vulnerable endpoints, effectively making all five endpoints unauthenticated attack surfaces.

5.  What cloud credentials, LLM API keys, and data pipeline access tokens are accessible from the Langflow server environment? If exploitation occurred, all credentials accessible to the Langflow process should be rotated.

Remediation recommendations

• Upgrade Langflow beyond version 1.7.3 immediately. CVE-2026-0770 is CISA KEV-listed with confirmed active exploitation; treating this as an emergency upgrade is warranted.
• Immediately restrict internet access to all Langflow instances pending upgrade confirmation. Place Langflow behind VPN-gated or IP-restricted access; the /api/v1/webhook/ and /api/v1/build_public_tmp/ endpoints must not be reachable from untrusted networks on vulnerable versions.
• Set AUTO_LOGIN=false in all Langflow deployments as a compensating control. While this does not eliminate the two fully unauthenticated endpoints, it restores authentication requirements to the three nominally authenticated endpoints.
• Rotate all credentials accessible from Langflow server environments — LLM API keys, cloud credentials (AWS, GCP, Azure), vector database API keys, and any other secrets configured in Langflow workflows — for any instance that was internet-accessible on a vulnerable version.
• Conduct a forensic review of Langflow server logs for exploitation indicators: unexpected process spawns, outbound connections from the Langflow process, or POST requests to the validate, webhook, or build_public_tmp API endpoints with unusual payloads.

Black Kite's Langflow - Jul2026 (Latest) FocusTag® details critical insights on the event for TPRM professionals.

Gitea (CVE-2026-58443)

What is this vulnerability?

CVE-2026-58443 (CVSS 9.6, GHSA-xxjv-752h-3vp2) is a critical incorrect authorization vulnerability in Gitea, a widely deployed self-hosted Git service. The flaw allows a public-only, write:repository-scoped API token to trigger a server-side write into a private pull request head branch — directly violating the security guarantee that public-only tokens cannot touch private resources. A working proof-of-concept is published in the GHSA advisory. No confirmed in-the-wild exploitation at time of publication. Fixed in Gitea v1.27.0. All releases up to and including v1.26.4 are affected. Approximately 2,228 Gitea instances running affected versions (v1.19.0–v1.26.4) are detectable on Shodan.

The vulnerability exists in Gitea's pull request update route: POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update. Gitea validates the token's public-only restriction against ctx.Repo.Repository — the route repository, which is the public base repository. The check therefore passes. UpdatePullRequest() then authorizes the pull request head repository using ordinary user RBAC and calls the pull update service. If the head repository is private, the token's public-only restriction is never re-applied to that private repository before Gitea pushes changes into it. The consequence: a token explicitly created to be restricted from private resources can cause Gitea to push public base commits into a private head branch. If Gitea Actions is enabled on the private head repository, the server-side push also triggers the matching workflow run — enabling an attacker to trigger CI/CD pipelines in a private repository using only a public-only token.

Why should TPRM professionals care?

Gitea is deployed as a self-hosted alternative to GitHub and GitLab across security-conscious enterprises, development teams, and organizations that require code sovereignty. The public-only token scope is a security primitive that developers and organizations rely on to partition automation access: a CI/CD pipeline or external integration that should touch only public code is given a public-only token precisely to ensure it cannot reach private repositories. CVE-2026-58443 breaks this guarantee at the framework level. For TPRM professionals, the CI/CD pipeline triggering side-effect is particularly significant: the flaw enables an attacker with a valid public-only token to trigger Gitea Actions workflows on private repositories, potentially initiating build, test, or deployment pipelines against private code — with all the environment variable, secret, and credential access that workflow execution entails. The full PoC in the advisory means exploitation requires minimal attacker sophistication.

What questions should TPRM professionals ask vendors?

1.  Has Gitea been upgraded to version 1.27.0 — the release fixing CVE-2026-58443? All versions through v1.26.4 are affected.

2.  Have Gitea API tokens carrying both public-only scope and write:repository scope been audited and rotated? Exploitation requires a valid token with this specific scope combination — revoking or rotating these tokens closes the exploitation path.

3.  If Gitea Actions is enabled on private repositories: have recent Actions run and job queues been reviewed for unexpected pushes or workflow triggers that may indicate exploitation? The GHSA advisory confirms that the vulnerability can trigger Actions runs on private repositories.

4.  Do any third-party integrations, external CI/CD systems, or automated pipelines hold public-only Gitea tokens for accessing the organization's Gitea instance? These third-party holders of public-only tokens represent the realistic attacker profile for this vulnerability.

5.  Is the Gitea instance internet-accessible, or restricted to internal networks? The exploitation requires a valid public-only token but does not require access beyond what any token holder already has to the public base repository.

Remediation recommendations

• Upgrade Gitea to v1.27.0 immediately. This is the only release addressing CVE-2026-58443.
• Audit and rotate all Gitea API tokens holding both public-only scope and write:repository scope. The combination of these two scopes is the prerequisite for exploiting the authorization bypass; rotating affected tokens eliminates the exploitation vector on unpatched instances pending upgrade.
• Review Gitea Actions run history on all private repositories for unexpected push-triggered workflow executions that may indicate prior exploitation. The GHSA advisory includes technical indicators of what an exploit-triggered run looks like in the Actions log.
• Restrict Gitea Actions execution on private repositories to trusted push sources. Implementing repository-level branch protection rules and workflow permission restrictions reduces the impact of the CI/CD pipeline trigger vector.
• Implement token lifecycle management policies for Gitea API tokens — enforce expiration, scope auditing, and rotation schedules. The public-only scope bypass exploits a trust boundary assumption that should be verified at the token issuance policy level, not assumed at runtime.

Black Kite's Gitea FocusTag® details critical insights on the event for TPRM professionals.

SharePoint - Jul2026 FocusTag® Update: CVE-2026-50522 Added to CISA KEV

Black Kite's existing SharePoint - Jul2026 FocusTag® has been further expanded this week with the addition of CVE-2026-50522, which has been listed in CISA's Known Exploited Vulnerabilities catalog. This marks the latest in a series of SharePoint vulnerability disclosures and KEV additions that have been building since the initial SharePoint - CVE-2026-45659 FocusTag® was published on July 3, 2026, and expanded on July 14 and July 16 with CVE-2026-56164 and CVE-2026-58644 respectively. The pattern of recurring SharePoint KEV additions reflects sustained active threat actor targeting of on-premises SharePoint Server, and TPRM professionals should confirm that all July 2026 SharePoint security patches are applied across vendor environments without delay.

For detailed technical analysis of the SharePoint vulnerability cluster — including vulnerability mechanics, TPRM vendor questions, and remediation guidance for the full SharePoint CVE set — refer to the earlier Focus Friday publications covering this FocusTag®:

• TPRM Insights on SharePoint, ProFTPD, Cacti, and Gogs (July 3, 2026)
• TPRM Insights on Progress ShareFile SZC, SonicWall SMA1000, MSSQL, Exchange Server, Zimbra, Roundcube, FreeBSD, and SharePoint (July 17, 2026)

How TPRM Professionals Can Leverage Black Kite for These Vulnerabilities

This week's nine FocusTags® demonstrate a consistent pattern across different technology layers: the most consequential vulnerabilities are distributed across platforms that vendor risk programs structurally struggle to track. WordPress secondary properties, self-hosted Gitea and RabbitMQ instances, Exim mail servers, and Langflow AI workflow platforms rarely appear in formal vendor technology disclosures — yet each hosted a critical vulnerability this week with direct exploitation consequences for data, credentials, and operational continuity.

The Langflow CISA KEV event illustrates the urgency dimension: EPSS 10.37% and active exploitation means the window between disclosure and mass exploitation has effectively closed. TPRM programs that depend on vendor self-reporting of patch status would learn about this exposure only after a breach. Black Kite's FocusTags® surface this exposure through external signal detection — identifying internet-facing Langflow instances in vendor external attack surfaces — enabling TPRM teams to initiate emergency verification engagement while exploitation is still preventable. The SolarWinds Serv-U and Oracle WebLogic batch disclosures demonstrate the prioritization challenge in high-volume patch weeks: sixteen Serv-U CVEs and eleven WebLogic CVEs require structured vendor engagement frameworks to ensure none are deprioritized or missed in a crowded patch queue.

Strengthening TPRM Outcomes with Black Kite’s FocusTags®

Black Kite's FocusTag® technology gives TPRM teams the operational intelligence needed to keep pace with an accelerating threat landscape — from CISA KEV-listed active exploitation events to multi-CVE batch disclosures requiring structured prioritization across diverse vendor technology stacks.

•  Continuous External Attack Surface Monitoring: FocusTags® correlate new vulnerability disclosures with vendor technology profiles derived from external signals — identifying internet-facing WordPress sites, self-hosted Gitea instances, and Langflow AI platforms that vendors never disclose in formal questionnaire responses.

•  KEV-Integrated Prioritization: CISA KEV listings and EPSS scores feed directly into FocusTag® prioritization, ensuring that active exploitation events like CVE-2026-0770 surface as immediate high-priority vendor engagement triggers rather than being buried in patch queues.

•  Batch Disclosure Management: Multi-CVE patch events — SolarWinds Serv-U's 16 CVEs, Oracle WebLogic's 11 CVEs — are consolidated into single FocusTags® with structured vendor questions, enabling TPRM teams to manage high-volume disclosure weeks without missing individual CVEs.

•  Continuous Risk Score Integration: FocusTag® exposure updates vendor risk ratings in real time, ensuring that critical vulnerability exposure is immediately reflected without waiting for scheduled assessment cycles.

About Focus Friday

Every week, we delve into the realms of critical vulnerabilities and their implications from a Third-Party Risk Management (TPRM) perspective. This series is dedicated to shedding light on pressing cybersecurity threats, offering in-depth analyses, and providing actionable insights.

FocusTags® in the Last 30 Days

• WordPress - wp2shell : CVE-2026-63030, CVE-2026-60137, REST API Batch-Route Confusion Vulnerability and SQL Injection Vulnerability Leading to Unauthenticated Remote Code Execution in WordPress Core.
• NGINX - Jul2026 : CVE-2026-42533, CVE-2026-60005, CVE-2026-56434, Heap-Based Buffer Overflow Vulnerability, Uninitialized Memory Access Vulnerability, and Use-After-Free Vulnerability in NGINX.
• SolarWinds Serv-U - Jul2026 : CVE-2026-28302, CVE-2026-28304, CVE-2026-28305, CVE-2026-28306, CVE-2026-28307, CVE-2026-28308, CVE-2026-28309, CVE-2026-28310, CVE-2026-28311, CVE-2026-28312, CVE-2026-28313, CVE-2026-28314, CVE-2026-28315, CVE-2026-28316, CVE-2026-28317, CVE-2026-28321, Insecure Direct Object Reference, Privilege Escalation, Remote Code Execution, Broken Access Control, and Stored Cross-Site Scripting Vulnerabilities in SolarWinds Serv-U.
• Oracle WebLogic - Jul2026 : CVE-2026-60206, CVE-2026-60205, CVE-2026-60204, CVE-2026-60202, CVE-2026-60198, CVE-2026-60294, CVE-2026-60200, CVE-2026-60291, CVE-2026-60292, CVE-2026-60199, CVE-2026-60208, Unauthenticated Remote Code Execution and Unauthorized Data Access Vulnerabilities in Oracle WebLogic Server.
• Zimbra - Jul2026 (Latest) : No CVE, Command Injection Vulnerability in SNMP Monitoring Component and Cross-Site Scripting Vulnerabilities in Zimbra Collaboration Suite Classic Web Client.
• Exim Mail - Jul2026 : GCVE-25-2026-07-45-1, Local Directory Traversal Vulnerability Leading to Privilege Escalation in Exim Mail Transfer Agent.
• RabbitMQ : CVE-2026-57219, CVE-2026-57221, TLS Client Authentication Bypass Vulnerability, OAuth2 JWKS Verification Bypass Vulnerability, OAuth Client Secret Exposure Vulnerability, and Cross-Tenant Authorization Bypass Vulnerability in RabbitMQ Server.
• Langflow - Jul2026 (Latest) : CVE-2026-0770, CVE-2026-5027, Unsafe Code Execution Vulnerability Leading to Unauthenticated Remote Code Execution in Langflow.
• Gitea : CVE-2026-58443, Incorrect Authorization Vulnerability Allowing Public-Only API Tokens to Trigger Writes to Private Repository Branches in Gitea.
• Progress ShareFile SZC : CVE Pending, Authenticated Path Traversal Vulnerability Allowing Arbitrary File Read, Arbitrary File Write, and Directory Enumeration in Progress ShareFile Storage Zone Controller.
• SonicWall SMA1000 - Jul2026 : CVE-2026-15409, CVE-2026-15410, Unauthenticated Server-Side Request Forgery Vulnerability and Post-Authentication Code Injection Vulnerability in SonicWall SMA1000.
• MSSQL - Jul2026 : CVE-2026-42990, CVE-2026-54117, CVE-2026-54118, CVE-2026-47295, CVE-2026-54116, CVE-2026-50468, Heap-Based Buffer Overflow Vulnerability, Deserialization of Untrusted Data Vulnerabilities, SQL Injection Vulnerability, and Information Disclosure Vulnerabilities in Microsoft SQL Server.
• Exchange Server - Jul2026 : CVE-2026-55008, CVE-2026-55005, CVE-2026-55009, CVE-2026-55006, Cross-Site Scripting Vulnerability, Heap-Based Buffer Overflow Vulnerability, Deserialization of Untrusted Data Vulnerability, and Privilege Escalation Vulnerability in Microsoft Exchange Server.
• Zimbra - Jul2026 : No CVE, Stored Cross-Site Scripting Vulnerability in Zimbra Collaboration Suite Classic Web Client.
• Roundcube - Jul2026 : CVE-2026-54433, Zero-Click Stored Cross-Site Scripting Vulnerability in Roundcube Webmail.
• FreeBSD - Jul2026 : CVE-2026-49418, CVE-2026-49419, CVE-2026-49415, Use-After-Free Vulnerability, Jail Reference Count Underflow Vulnerability, and Time-of-Check Time-of-Use Race Condition Vulnerability in FreeBSD.
• JoomShaper SP Page Builder : CVE-2026-48908, Critical Unauthenticated Remote Code Execution Vulnerability in JoomShaper SP Page Builder.
• Langflow - CVE-2026-55255 : CVE-2026-55255, High-Severity Insecure Direct Object Reference Vulnerability in Langflow.
• ActiveMQ - Jul2026 : CVE-2026-53916, CVE-2026-50734, CVE-2026-50750, CVE-2026-49432, CVE-2026-54475, CVE-2026-49877, CVE-2026-49434, CVE-2026-53917, CVE-2026-52760, Multiple Apache ActiveMQ Vulnerabilities.
• SharePoint - CVE-2026-45659 : CVE-2026-45659, High-Severity Deserialization of Untrusted Data Vulnerability in Microsoft SharePoint List Item Update Workflow Allowing Low-Privilege Network Remote Code Execution.
• ProFTPD : CVE-2026-35025, High-Severity ACL Bypass Vulnerability in ProFTPD via /proc/self/root RNFR Path Prefix Allowing Authenticated Access to Restricted Directories.
• Cacti - Jun2026 : CVE-2026-39893, CVE-2026-39948, CVE-2026-39955, CVE-2026-39938, Critical Pre-Authentication SQL Injection, Regex Validation Bypass, and Unauthenticated Local File Inclusion Vulnerabilities in Cacti.
• Gogs - Jun2026 : CVE-2026-52813, CVE-2026-52806, CVE-2026-52811, Critical Path Traversal, Git Hook Overwrite, Rebase Argument Injection, Arbitrary OS Command Execution, and Symlink File Write Vulnerabilities in Gogs Leading to Remote Code Execution and Persistent Backdoors.
• Squidbleed : CVE-2026-47729, CVE-2026-50012, Critical Heap Over-Read Vulnerability in Squid Proxy FTP Directory-Listing Parser Leading to Cleartext HTTP Request and Token Disclosure.
• UniFi OS Devices : CVE-2026-34908, CVE-2026-34909, CVE-2026-34910, CVE-2026-33000, CVE-2026-34911, Critical Improper Access Control, Path Traversal, Command Injection, and Information Disclosure Vulnerabilities in UniFi OS Devices.
• pgAdmin - Jun2026 : CVE-2026-12046, CVE-2026-12045, CVE-2026-12048, Critical Unauthenticated Remote Code Execution, AI Assistant Transaction Bypass, OS Command Execution, and Stored XSS Vulnerabilities in pgAdmin 4.
• FreeBSD - Jun2026: CVE-2026-45257, High-Severity Local Privilege Escalation Vulnerability in FreeBSD KTLS sendfile(2) Handling Allowing Page Cache Modification and Root Compromise.
• TinyProxy - Jun2026 : CVE-2026-54388, CVE-2026-54387, CVE-2026-55202, Critical HTTP Request Smuggling, CL/TE Desynchronization, Request Injection, Cache Poisoning, Access Control Bypass, and StatHost Bypass Vulnerabilities in TinyProxy.

See Black Kite's full CVE Database and the critical TPRM vulnerabilities that have an applied  FocusTags® at https://blackkite.com/cve-database.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-63030

https://nvd.nist.gov/vuln/detail/CVE-2026-60137

https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-ff9f-jf42-662q

https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-fpp7-x2x2-2mjf

https://wordpress.org/news/2026/07/wordpress-7-0-2-release/

https://www.cycognito.com/blog/emerging-threat-cve-2026-63030-cve-2026-60137-wordpress-core-unauthenticated-rce-via-wp2shell/

https://www.cve.org/CVERecord?id=CVE-2026-42533

https://www.cve.org/CVERecord?id=CVE-2026-60005

https://www.cve.org/CVERecord?id=CVE-2026-56434

https://securityonline.info/nginx-code-execution-cve-2026-42533/

https://my.f5.com/manage/s/article/K000162098

https://documentation.solarwinds.com/en/success_center/servu/content/release_notes/servu_2026-3_release_notes.htm

https://nvd.nist.gov/vuln/detail/CVE-2026-28302

https://nvd.nist.gov/vuln/detail/CVE-2026-28304

https://nvd.nist.gov/vuln/detail/CVE-2026-28305

https://nvd.nist.gov/vuln/detail/CVE-2026-28306

https://nvd.nist.gov/vuln/detail/CVE-2026-28307

https://nvd.nist.gov/vuln/detail/CVE-2026-28308

https://nvd.nist.gov/vuln/detail/CVE-2026-28309

https://nvd.nist.gov/vuln/detail/CVE-2026-28310

https://nvd.nist.gov/vuln/detail/CVE-2026-28311

https://nvd.nist.gov/vuln/detail/CVE-2026-28312

https://nvd.nist.gov/vuln/detail/CVE-2026-28313

https://nvd.nist.gov/vuln/detail/CVE-2026-28314

https://nvd.nist.gov/vuln/detail/CVE-2026-28315

https://nvd.nist.gov/vuln/detail/CVE-2026-28316

https://nvd.nist.gov/vuln/detail/CVE-2026-28317

https://nvd.nist.gov/vuln/detail/CVE-2026-28321

https://www.oracle.com/security-alerts/cpujul2026.html

https://www.cve.org/CVERecord?id=CVE-2026-60206

https://www.cve.org/CVERecord?id=CVE-2026-60205

https://www.cve.org/CVERecord?id=CVE-2026-60204

https://www.cve.org/CVERecord?id=CVE-2026-60202

https://www.cve.org/CVERecord?id=CVE-2026-60198

https://www.cve.org/CVERecord?id=CVE-2026-60294

https://www.cve.org/CVERecord?id=CVE-2026-60200

https://www.cve.org/CVERecord?id=CVE-2026-60291

https://www.cve.org/CVERecord?id=CVE-2026-60292

https://www.cve.org/CVERecord?id=CVE-2026-60199

https://www.cve.org/CVERecord?id=CVE-2026-60208

https://securityonline.info/oracle-weblogic-server-vulnerability-cve-2026-60206/

https://wiki.zimbra.com/wiki/Zimbra_Releases/10.1.20

https://blog.zimbra.com/2026/07/patch-release-update-zimbra-10-1-20/

https://securityonline.info/zimbra-10-1-20-vulnerabilities/

https://www.exim.org/static/doc/security/EXIM-Security-2026-06-22.1/EXIM-Security-2026-06-22.1.txt

https://seclists.org/oss-sec/2026/q3/

https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-cw8c-4m83-9c6w

https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-37wx-r6q9-6fhj

https://thehackernews.com/2026/07/rabbitmq-flaws-could-leak-oauth-secrets.html

https://www.cve.org/CVERecord?id=CVE-2026-0770

https://github.com/langflow-ai/langflow

https://github.com/affix/CVE-2026-0770-PoC

https://github.com/go-gitea/gitea/security/advisories/GHSA-xxjv-752h-3vp2

https://securityonline.info/gitea-vulnerability/

https://gbhackers.com/critical-gitea-flaw-trigger-actions-workflows/

https://blackkite.com/blog/tprm-insights-sharepoint-proftpd-cacti-gogs

https://blackkite.com/blog/tprm-insights-progress-sharefile-szc-sonicwall-sma1000-mssql-exchange-server-zimbra-roundcube-freebsd-and-sharepoint