Weekly Cyberattack Roundups

Weekly Cyberattack Roundup: Six Newly Cataloged Exploited Vulnerabilities, July 20–26, 2026

Five affected technology groups and their confirmed-exploitation signals connected to inventory, exposure, containment, security update, and evidence-validation paths
Intelligence Center
Weekly Cyberattack Roundups
Last fact-checked July 2026
Analysis by Ali Hassani, CISO

CISA added six vulnerabilities to its Known Exploited Vulnerabilities catalog during the completed week of July 20–26, 2026. The affected technologies span security administration, on-premises collaboration, WordPress, an AI workflow platform, and network routing.

This roundup does not assume that every organization owns these products or that every affected system was compromised. It separates CISA’s confirmed exploitation signal from local exposure, applies the vendor’s current remediation guidance, and identifies the evidence an IT or security leader should request before closing the issue.

Week at a glance

Measure Confirmed weekly result
Completed date range July 20–26, 2026
CISA KEV additions 6 vulnerabilities
Affected technology groups Check Point SmartConsole, Microsoft SharePoint, WordPress Core, Langflow, and DD-WRT
CISA ransomware-use field Unknown for all six entries as of the fact check
Most urgent common task Confirm affected assets and exposure, follow the current vendor action, preserve evidence where exploitation was possible, and validate the result

“Unknown” in the ransomware field does not mean that ransomware was ruled out. It means CISA’s catalog did not identify known ransomware-campaign use for those entries at the time reviewed.

The six CISA KEV additions

CVE-2026-16232 — Check Point SmartConsole

CISA added CVE-2026-16232 on July 22. Its catalog describes an improper-authentication vulnerability in Check Point SmartConsole that could allow an unauthenticated remote attacker to obtain an application login token and authenticate with administrative privileges.

What to verify

  • Which SmartConsole versions and management environments are present?
  • Is the affected service reachable from an untrusted or partner network?
  • Has the organization applied the current action in Check Point advisory SK185169?
  • Do management, authentication, and administrative logs show unusual token issuance or sign-in activity?
  • Were any privileged configuration changes made during the exposure window?

Security-management software is a high-impact asset. A remediation ticket should include both version evidence and a review of relevant administrative activity rather than ending with “update installed.”

CVE-2026-50522 — Microsoft SharePoint

CISA added CVE-2026-50522 on July 22. The catalog describes deserialization of untrusted data in Microsoft SharePoint that could allow an unauthorized network attacker to execute code.

The affected product record should be matched carefully to the organization’s actual SharePoint deployment. Cloud services and customer-managed SharePoint servers do not always share the same responsibility or update path.

What to verify

  • Is an affected SharePoint product and build actually installed?
  • Which servers are internet-reachable or accessible through remote and trusted network paths?
  • What action does the current Microsoft Security Response Center record require?
  • Are web, application, operating-system, identity, and endpoint logs available for the exposure period?
  • Was remediation validated on every server in the farm, including disaster-recovery and standby systems?

If a server was reachable before remediation, patch validation and compromise assessment are separate workstreams.

CVE-2026-60137 — WordPress Core

CISA added CVE-2026-60137 on July 21. CISA’s description says the SQL-injection issue can occur when a plugin or theme passes untrusted input to a parameter and can be chained with CVE-2026-63030.

The official WordPress 7.0.2 release notice identifies a critical and a high-severity security issue, recommends immediate updating, and lists backported fixes for supported affected branches. The notice states that versions before 6.8 are not affected and distinguishes the backport coverage.

What to verify

  • What WordPress core version is running on every public, staging, development, and forgotten site?
  • Did automatic updating complete successfully, or is the site held on a managed or manual update process?
  • Are installed plugins and themes actively maintained and compatible with the corrected core branch?
  • Were web application firewall, access, database, file-integrity, and administrator logs retained?
  • Does post-update testing confirm normal site, login, form, API, caching, and administrative behavior?

Do not infer safety from a hosting brand, a plugin list, or an enabled auto-update setting. Record the version observed after the update.

CVE-2026-63030 — WordPress Core

CISA also added CVE-2026-63030 on July 21. Its catalog describes an interpretation-conflict vulnerability that can be chained with CVE-2026-60137 and lead to SQL injection and remote code execution.

Because the two WordPress issues can interact, inventory and remediation should treat the vendor’s release as one coordinated action. Closing one CVE while leaving the affected core branch unverified does not demonstrate that the site is protected.

What to verify

  • Is the corrected WordPress branch installed?
  • Were all nodes, containers, replicas, and recovery copies updated?
  • Did the team check for unexpected code, files, users, scheduled tasks, database changes, or administrator sessions where exposure existed?
  • Is the update recorded in change control with a rollback path and validation evidence?

For a business site, availability matters, but delaying a security release indefinitely because of plugin uncertainty creates a different operational risk. Test rapidly in a representative environment, back up the site, then apply and validate the supported update.

CVE-2026-0770 — Langflow

CISA added CVE-2026-0770 on July 21. The catalog describes inclusion of functionality from an untrusted control sphere that could allow remote code execution on affected Langflow installations. CISA links to the official Langflow 1.9.0 release.

AI workflow platforms can connect to model providers, databases, files, APIs, automation tools, and stored secrets. The potential business consequence therefore depends on the permissions and data paths surrounding the affected installation, not only the application itself.

What to verify

  • Is Langflow deployed, and what exact version is running?
  • Is the service public, partner-accessible, or reachable only from a controlled administration path?
  • Which model providers, databases, storage locations, automation tools, and secrets can the platform access?
  • Has the current vendor-supported fixed release or mitigation been applied?
  • Are application, container, host, identity, network, and secret-access logs available for review?

Avoid exposing experimental AI tooling directly to the internet simply because it is considered a development system. Development platforms often hold broad credentials and copies of sensitive data.

CVE-2021-27137 — DD-WRT

CISA added the older CVE-2021-27137 on July 21. The catalog describes a stack-based buffer-overflow issue involving UPnP that could allow unauthenticated code execution. CISA notes that the issue may affect a common component or implementation and directs users to check specific vendor patching status.

The older CVE year is an important operational lesson: discovery of active exploitation can change the priority of a vulnerability long after its initial disclosure.

What to verify

  • Are DD-WRT or related affected implementations present in offices, branches, labs, home-office kits, temporary sites, or unmanaged network equipment?
  • Is UPnP enabled where it is not required?
  • Is the device still supported and able to receive a trusted corrected build?
  • Can the router be replaced if vendor support or provenance is uncertain?
  • Were configuration, administrator, and network-access records reviewed where exposure was plausible?

Unsupported edge devices should not remain indefinitely because they still pass traffic. Their administrative and update limitations can make replacement the more defensible action.

Infrastructure security engineers inspecting rack-mounted servers, network appliances, and fiber connections during a controlled datacenter maintenance window
A coordinated maintenance window should confirm actual assets, exposure paths, installed fixes, and post-change service health across every affected on-premises system.

A defensible response sequence

1. Confirm ownership before declaring impact

Search authenticated asset inventory, endpoint and server management, cloud and hosting records, vulnerability scans, network discovery, procurement, support contracts, and application-owner records. Product names in unauthenticated scans can be incomplete or misleading, so preserve the evidence used to confirm or rule out an asset.

2. Determine effective exposure

“Not directly on the internet” is not the end of the analysis. Consider:

  • remote access and VPN paths;
  • partner, vendor, and support connections;
  • identity and single-sign-on trust;
  • management networks;
  • public reverse proxies;
  • cloud load balancers and gateways;
  • lateral access from user networks; and
  • shared credentials or automation accounts.

The goal is to identify whether an attacker could realistically reach the vulnerable function.

3. Follow the current vendor action

Use the vendor’s current advisory, supported fixed version, prerequisites, and known limitations. CISA’s catalog is the exploitation signal, but the vendor normally provides product-specific remediation.

For unsupported products, record the decision to isolate, disable, replace, or discontinue the affected service. A compensating control needs an owner, expiration date, monitoring requirement, and residual-risk decision.

4. Preserve and review evidence where exposure existed

Evidence needs vary by product, but may include:

  • authentication and administrator events;
  • application and web access logs;
  • endpoint or server telemetry;
  • file and configuration changes;
  • database activity;
  • cloud and identity audit records;
  • firewall, proxy, and remote-access logs; and
  • security-management configuration history.

Absence of alerts is not proof of no exploitation when the relevant logs were never enabled or were overwritten.

5. Validate remediation and service health

Verify the installed version or configuration from an authoritative source, re-scan using an appropriate method, test business function, check that security controls still operate, and record the result. WordPress sites, SharePoint farms, security-management systems, routers, and AI workflow platforms require different validation steps.

The broader CISA KEV prioritization model explains how to combine known exploitation with asset confirmation, exposure, business criticality, compensating controls, and remediation evidence.

What leaders should request by the next status meeting

Ask for a short evidence packet, not a verbal “we patched it”:

  • confirmed affected and unaffected assets;
  • exposure and business-owner mapping;
  • vendor advisory and action selected;
  • containment or update timestamp;
  • validation result;
  • evidence reviewed for prior exploitation;
  • logging limitations;
  • open exceptions and expiration dates; and
  • accountable owner for any remaining work.

This structure helps executives distinguish real risk reduction from ticket movement.

Six infrastructure zones feeding asset, exposure, logging, remediation, rescan, and exception evidence into a central vulnerability validation workflow
A defensible vulnerability evidence packet links each affected asset to exposure, vendor action, preserved logs, remediation timing, rescan results, and unresolved exceptions.

What this roundup does not establish

The weekly catalog changes do not prove:

  • that a specific organization uses an affected product;
  • that an affected product is exposed;
  • that exploitation succeeded in a particular environment;
  • that ransomware was involved;
  • that one attacker or campaign is responsible for all six entries;
  • that remediation can ignore change, availability, or safety requirements; or
  • that installing an update removes an attacker who may already have gained access.

Those conclusions require asset-specific and incident-specific evidence.

Turn the weekly signal into verified action

OC Security Audit can independently assess vulnerability intake, affected-asset confirmation, exposure, remediation, evidence review, rescanning, and exception governance. Contact OC Security Audit for a focused vulnerability-management review.

Analysis prepared and reviewed by Ali Hassani, CISO.

Sources

The editorial standards explain the Intelligence Center’s vulnerability-source hierarchy, update checks, and corrections.

Last fact-checked July 2026. CISA and vendor records can change; verify the live catalog entry and current vendor advisory before acting.