Dispatch 007: TeamPCP poisoned the VS Code Nx Console extension and cloned GitHub's internal repositories, Trend Micro Apex One is being used to deliver malware to the endpoints it manages, Drupal has an actively exploited SQL injection on PostgreSQL backends, and the Secure Boot deadline is 33 days out with a confirmed OEM gap on pre-2018 hardware
The same group behind the Bitwarden CLI supply chain attack poisoned the Nx Console VS Code extension on May 20, harvested credentials from developer machines for 18 minutes, and used exfiltrated SSH keys to clone approximately 3,800 GitHub internal repositories; the SMB action is a VS Code extension audit and an auto-update policy decision, not a GitHub-specific response. CVE-2026-34926 in Trend Micro Apex One is a confirmed zero-day being exploited in the wild: an attacker with Apex One server admin credentials can modify the agent communication table and push malicious code to every managed endpoint, turning the security platform into a malware delivery mechanism; the fix is version 14.0.0.17079, KEV June 4 deadline. CVE-2026-9082 is an actively exploited SQL injection in Drupal core that affects only PostgreSQL-backed sites; KEV-listed May 22 with a May 27 deadline that has passed and a public scanner already in circulation. With 33 days to the June 26 Secure Boot certificate expiration, pre-2018 Dell, HP, and Lenovo hardware has documented capsule update issues, and the Hyper-V host-before-guest deployment ordering requirement is confirmed and consequential. And CVE-2026-5194 in wolfSSL has been patched upstream since April 8 with no major network vendor firmware advisory yet; this month is the time to inventory which perimeter and IoT devices in your environment are likely affected and set a monitoring cadence before advisories land.
Patch today
Items with immediate action required.
-
CVE-2026-9082 in Drupal core, actively exploited SQL injection via PostgreSQL EntityQuery, KEV-listed May 22, May 27 deadline passed, public scanner in circulation
Update Drupal to 10.2.8, 10.3.6, or 11.1.2 on every managed site backed by PostgreSQL. MySQL and MariaDB sites are not affected by this specific flaw. If you are not certain which database backend a managed Drupal site uses, treat it as potentially affected until confirmed otherwise.
Why it matters: CVE-2026-9082 is a SQL injection vulnerability in Drupal core's EntityQuery condition handler that applies specifically to sites configured to use PostgreSQL as the database backend. The flaw is in how EntityQuery constructs database queries when processing certain condition operators; an unauthenticated remote attacker sends a crafted HTTP request to any Drupal route that triggers an EntityQuery execution, the malicious input passes through the condition handler without sanitization, and the resulting query executes arbitrary SQL against the PostgreSQL database. Depending on PostgreSQL's configuration and the database user's privilege level, exploitation can produce data disclosure, data modification, or in configurations where PostgreSQL's COPY TO/FROM PROGRAM extension is accessible, remote code execution on the database host. Drupal disclosed the vulnerability on May 21, rated it highly critical, and the Drupal Security Team confirmed active exploitation before the advisory was public. CISA KEV-listed CVE-2026-9082 on May 22 with a federal remediation deadline of May 27, which has passed. A working Drupal scanner that tests for the vulnerability was published to GitHub on May 22, the same day as the KEV listing, which is faster than the usual exploit-to-scanner timeline and reflects how straightforward the injection is to automate. The audience scope is narrower than a typical Drupal advisory: MySQL and MariaDB-backed sites are not affected because the vulnerable code path is specific to PostgreSQL's query construction behavior. However, MSPs managing a portfolio of Drupal sites often do not have per-site database backend documentation readily available, which means the safe operational posture is to treat every managed Drupal site as potentially affected until you have confirmed the database type.
What to do: Identify every Drupal site in your managed portfolio and confirm the database backend for each. The database type is configured in the Drupal settings.php file under the database connection array; the driver value of pgsql confirms PostgreSQL. If you use a hosting platform, cPanel, Plesk, or a managed WordPress-equivalent for Drupal, the database type is typically visible in the control panel's database management interface. For confirmed PostgreSQL sites, update Drupal core immediately to version 10.2.8, 10.3.6, or 11.1.2 depending on the current release branch. The update can be applied via Composer (composer update drupal/core --with-all-dependencies), via Drush (drush pm:update drupal/core), or via the Drupal administrative interface under Reports > Available updates for sites where admin-initiated updates are permitted. After updating, review the database access logs for the past seven days for unusual query patterns; the exploitation signature is unexpected SQL operators appearing in EntityQuery-generated queries in the database slow-query or general log. For sites where an update cannot be applied immediately, the Drupal Security Team has not published a configuration-level mitigation for this vulnerability; the temporary risk reduction is to restrict public access to the site at the web server or CDN level until the update can be applied. For MySQL and MariaDB sites: confirm the driver value in settings.php is mysql, then no action is required for this specific CVE. Document the finding in your asset inventory so this confirmation is available for future advisories.
This week
Worth investigating this week but not today.
-
TeamPCP poisoned the Nx Console VS Code extension on May 20 and used exfiltrated SSH keys to clone 3,800 GitHub internal repositories; the practitioner action is a VS Code extension audit and an auto-update policy decision
Audit VS Code extensions installed across your developer and MSP tooling environments this week and confirm whether Nx Console was installed between May 20 at approximately 14:00 UTC and 14:18 UTC. Beyond this specific incident, disable VS Code extension auto-update for extensions from publishers not on an explicitly approved list; the Bitwarden CLI and Nx Console poisonings are the second and third demonstrations of this attack surface in six weeks.
Why it matters: On May 20, 2026, TeamPCP, the group responsible for the Bitwarden CLI supply chain attack covered in dispatch-003, published a malicious build of the Nx Console VS Code extension to the Visual Studio Marketplace. The malicious version was live for approximately 18 minutes before Microsoft's Marketplace security scanning flagged and removed it. During that window the extension executed a credential harvesting payload on every machine where VS Code auto-updated Nx Console: the payload searched for 1Password vault files, GitHub tokens, SSH private keys, AWS credentials stored in ~/.aws/credentials, and MCP configuration files from Claude Code, Cursor, and similar AI coding assistants, then pushed the output to a public GitHub repository before using the exfiltrated SSH keys to authenticate to GitHub and clone repositories. TeamPCP used those cloned SSH keys to access approximately 3,800 GitHub internal repositories. GitHub confirmed on May 22 that no customer repository data was accessed; the scope was GitHub's own internal infrastructure. The practitioner concern here is not GitHub's breach. It is the VS Code extension auto-update mechanism and its demonstrated use as a repeatable attack surface. VS Code auto-updates extensions by default without any review gate between a publisher pushing a malicious update and it installing silently on every machine running that extension. TeamPCP has now demonstrated this attack surface twice in six weeks (Bitwarden CLI via npm, Nx Console via the VS Code Marketplace) with the same credential-harvesting payload pattern and the same exfiltration destination (public GitHub repositories). The target list is consistent: developer machines with cloud credentials, SSH keys, GitHub tokens, and AI tooling configurations. The 18-minute window on the Nx Console poisoning is shorter than the 93-minute Bitwarden CLI window, which suggests either improved detection on Microsoft's side or that the attacker is willing to accept shorter windows in exchange for faster iteration.
What to do: Check VS Code extension installation logs on developer and MSP automation machines for Nx Console installations or updates between May 20 at 14:00 UTC and 14:18 UTC. On Windows, VS Code extension activity is logged in %APPDATA%\Code\logs; on macOS and Linux, the equivalent is ~/.config/Code/logs or ~/Library/Application Support/Code/logs respectively. If you find a hit in that window, treat the machine as compromised: rotate every SSH key, GitHub personal access token, AWS IAM key, and API credential reachable from that machine, search your GitHub organization for repositories created between May 20 at 14:00 UTC and May 21 that your team did not create, and audit MCP configuration files on the affected machine for any connections to external services using credentials that need rotation. For the broader auto-update policy: in VS Code, navigate to File > Preferences > Settings and set Extensions: Auto Update to false, or set it to onlyEnabledExtensions if you want to restrict auto-update to a curated approved list rather than disabling it entirely. In enterprise environments managed through Intune or Group Policy, the VS Code settings.json can be deployed centrally with extensions.autoUpdate set to false as a managed policy. This does not prevent extension updates; it requires a deliberate action to update, which is the review gate the current default setting omits. Build an approved extension list for your development and MSP tooling environments and enforce it; the VS Code Marketplace has no equivalent of the Chrome Web Store's developer program verification, and publisher impersonation remains possible alongside direct publisher account compromise.
-
CVE-2026-34926 in Trend Micro Apex One, confirmed zero-day, attacker with server admin credentials can inject code into the agent communication table and push it to every managed endpoint, KEV June 4 deadline
Update Apex One on-premise server and agents to build 17079 or later. The CVSS score of 6.7 reflects the admin credential prerequisite but understates the business risk: the compromised system is the endpoint security management plane for your entire fleet. An attacker who clears the access bar gets silent code delivery to every device Apex One manages.
Why it matters: CVE-2026-34926 is a directory traversal vulnerability (CWE-23) in the on-premises Trend Micro Apex One server. The attack requires two preconditions: local access to the Apex One server and valid administrator credentials for the Apex One management console. An attacker who meets those preconditions uses a path traversal sequence to overwrite a key table in the Apex One server's internal database, injecting malicious code that is then treated as legitimate configuration by the server's agent communication process. The next time the Apex One server communicates with its managed endpoint agents, the injected code is distributed and executed on every enrolled device. The CVSS score is 6.7, rated medium, because the attack complexity and privilege requirements are both high. The business risk is not reflected in that score. Trend Micro Apex One is an endpoint security platform whose management server holds trusted authority over every endpoint it manages; the agent installed on each managed device accepts instructions from the server without secondary verification. Turning that trust relationship against the organization is precisely what this vulnerability enables. Trend Micro's own incident response team discovered the flaw during an active incident investigation, which is how the company confirmed in-the-wild exploitation before the advisory was public. CISA KEV-listed CVE-2026-34926 on May 22 with a federal deadline of June 4. The Apex One May 2026 bulletin also addresses CVE-2026-34927 through CVE-2026-34930 and CVE-2026-45206 through CVE-2026-45208, which are local privilege escalation flaws in the Apex One and Standard Endpoint Protection agents rated CVSS 6.8 to 7.8; all are addressed in the same build 17079 update.
What to do: Identify every on-premise Trend Micro Apex One deployment in your environment. The current server version is visible in the Apex One web console under Administration > Apex One Server. The fixed build is 17079; if the displayed build number is lower than 17079, the server is vulnerable. Apply the update through the Apex One management console under Administration > Update > Server > Manual Update, or download the Critical Patch from the Trend Micro Support Portal if the console update mechanism is not available. After updating the server, push the updated component packages to all managed agents through the console under Update > Deploy Agents. Both the server and agents require the update; a patched server that continues to manage agents on older builds still resolves the specific code injection vector of CVE-2026-34926, but the agents' local privilege escalation flaws (CVE-2026-34927 through CVE-2026-45208) remain until the agent build is also updated. After updating, review the Apex One server logs under Logs > System Events for any unexpected component updates or configuration changes pushed to agents since May 1; the exploitation signature is an unauthorized modification to the server's key table, which would appear as a configuration change event that no administrator initiated. Restrict access to the Apex One server administrative console to a dedicated management VLAN or VPN-only network segment if it is not already restricted; the admin credential prerequisite for exploitation makes network access control a meaningful second layer of defense.
-
Secure Boot certificate deadline is June 26, 33 days out; pre-2018 OEM hardware has confirmed capsule update failures, Hyper-V host-before-guest ordering is required and consequential, and Windows Server manual deployment is the gap most environments have not closed
This month, complete the UEFICA2023Status registry audit across your fleet, manually deploy the 2023 certificates to all Windows Server instances and Generation 2 Hyper-V VMs, and flag any Dell, HP, or Lenovo hardware manufactured before 2018 for OEM-direct remediation before attempting the certificate update. Do not update a guest VM before updating the Hyper-V host that runs it.
Why it matters: The June 26 Secure Boot deadline has appeared in prior issues as a background item. At 33 days, it becomes the kind of thing that needs to be done this week rather than tracked for next month. Three specific details that surfaced in the past week elevate it from calendar awareness to immediate action. First, pre-2018 hardware: Dell, HP, and Lenovo models manufactured before 2018 have documented failures in the UEFI capsule update mechanism that delivers the certificate change. The capsule update relies on the UEFI SetVariable() call with a specific attribute combination that older firmware implementations do not correctly support. Attempting the certificate update on affected hardware without first applying an OEM firmware update that resolves the capsule handling can produce a failed update state that is difficult to recover without a full BIOS flash. Dell PowerEdge servers predating 2018 are particularly noted in the Windows Server Secure Boot playbook as requiring OEM firmware review before certificate deployment; the same applies to HP ProLiant Gen9 and earlier, and Lenovo ThinkSystem V2 and earlier. If your server fleet includes any hardware in those categories, the correct sequence is OEM firmware update first, certificate deployment second, not both simultaneously. Second, Hyper-V ordering: if a Generation 2 VM's guest OS receives the Secure Boot certificate update before the Hyper-V host's own firmware exposes virtual firmware that trusts the new certificate, the VM may fail to start after the deadline. The host must be updated first. This ordering dependency applies to both on-premises Hyper-V and Azure Stack HCI environments; Generation 1 VMs do not use Secure Boot and are not affected. Third, Windows Server manual deployment: unlike Windows 11, Windows Server does not receive the 2023 Secure Boot certificate updates through Windows Update automatically. The update must be triggered manually via one of three methods, a registry key, Group Policy, or a PowerShell deployment script, and in a typical enterprise environment the certificates propagate within approximately 12 hours of the trigger. Any Windows Server instance that has not received this manual trigger has not begun the certificate update process, regardless of how current its cumulative updates are.
What to do: Complete three tasks this month in sequence. First, run the fleet audit: query the UEFICA2023Status registry key at HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\State on every Windows device in your environment. A value of 'Updated' means the certificate is applied. Windows System Event ID 1808 confirms the update; Event ID 1801 means it has not applied and requires investigation. For Windows 11 and Windows 10 ESU devices that show 1801, check whether the May cumulative update has been applied; the May cycle is delivering the certificate rollout to those devices via Windows Update automatically. For Windows Server, see the second task. Second, manually trigger the certificate deployment on every Windows Server instance: set the AvailableUpdates registry value to 0x5944 (decimal 22852) under HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot, or enable the 'Enable Secure Boot Certificate Deployment' Group Policy at Computer Configuration > Administrative Templates > Windows Components > Secure Boot. Either method triggers the deployment; the registry key is faster for scripted deployment across a fleet. After setting the trigger, allow 12 hours and then re-query UEFICA2023Status to confirm 'Updated.' Apply the same process to every Generation 2 Hyper-V VM, but only after the host's own Secure Boot status shows 'Updated.' Third, flag pre-2018 hardware: before triggering the certificate update on any Dell server predating 2018, any HP ProLiant Gen9 or earlier, or any Lenovo ThinkSystem V2 or earlier, check the OEM support portal for a firmware advisory specific to that model and the 2026 Secure Boot certificate transition. If the OEM has not published a firmware update for the specific model, contact OEM support before proceeding; an unresolved capsule update failure on a production server is a worse outcome than a planned OEM support engagement before the June 26 deadline.
Monthly or quarterly review
Add to longer-term planning cycles.
-
CVE-2026-5194 in wolfSSL has been patched upstream since April 8 but no major network vendor has shipped a firmware advisory yet; this month is the time to inventory which of your perimeter and IoT devices are likely affected and set a monitoring cadence
Check your router, firewall, and NAS vendor advisory pages for any mention of wolfSSL or CVE-2026-5194 before your next quarterly review. Devices that are end-of-life and running wolfSSL-based firmware will not receive a fix. If you do not know which devices in your environment use wolfSSL, that is the deliverable for this month.
Why it matters: CVE-2026-5194 is a certificate verification bypass in the wolfSSL TLS library that allows an attacker to present a forged digital certificate and have a vulnerable device accept it as legitimate, enabling man-in-the-middle attacks and authentication bypass across any connection the device handles. wolfSSL is embedded in an estimated five billion devices including routers, NAS appliances, IoT sensors, VPN clients, and industrial controllers; Red Hat's independent assessment assigned it a CVSS of 10.0. wolfSSL patched the flaw in version 5.9.1, released April 8. The dispatch has noted this vulnerability in every issue since dispatch-004 with the same holding pattern: no downstream firmware advisories from Ubiquiti, Netgate, Fortinet, or other major network vendors have been confirmed. That silence is not necessarily reassuring. The gap between a library fix and the firmware that embeds it reaching end devices is historically measured in months rather than weeks, and devices that are end-of-life or out of active support will never receive the fix regardless of how long the wait is. The operational problem this creates is specific to the SMB environment: most managed environments contain a mix of actively supported and quietly end-of-life devices at the network perimeter and in the IoT layer, the software bill of materials for those devices is rarely documented, and the firmware update process for each vendor is sufficiently different that a bulk check is not straightforward. The window between a library fix and active exploitation of downstream devices is an expected feature of the embedded device vulnerability lifecycle, not an exception to it.
What to do: This month, complete two tasks that set you up for faster action when firmware advisories eventually land. First, inventory your perimeter and IoT devices by vendor and model, and check each vendor's security advisory page for any bulletin mentioning wolfSSL or CVE-2026-5194. The vendors most likely to have embedded wolfSSL in relevant products are Ubiquiti (UniFi gateways and security appliances), Netgate (pfSense and TNSR appliances), Synology and QNAP (NAS devices using wolfSSL for HTTPS and VPN), Axis Communications (network cameras), and various consumer router manufacturers including TP-Link, Asus, and D-Link product lines that remain supported. Search each vendor's security advisory index for 'wolfSSL' and 'CVE-2026-5194' specifically; generic firmware release notes may not surface library-level dependency updates. For Fortinet specifically, check FortiGuard Labs at fortiguard.com/psirt and filter by date since April 8; no advisory has been confirmed as of this writing but the FortiOS and FortiClient product families both have documented wolfSSL dependencies in prior research. Second, flag any device in your inventory that is end-of-life with the vendor and remove it from the set of devices you expect to receive a fix. A device that will not receive a firmware update is a permanent liability for this class of vulnerability; the June 26 Secure Boot deadline is producing replacement conversations for out-of-support hardware, and CVE-2026-5194 is another input into that same conversation. Set a monthly check on this item; the first major vendor to ship a wolfSSL advisory will likely produce an acceleration in others, and you want to be positioned to deploy firmware updates within days rather than weeks when that happens.