Security

Chainstack: customer account data read over five days

Chainstack disclosed on 3 November that an attacker was in a development environment from 26 October, reached parts of production on 29 October, and was cut off on 31 October. The customer account database was read: organisation names, account holder names, member email addresses and password hashes. Systems holding node credentials were reachable too.

Affected

Chainstack managed blockchain platform, a hosted service.

Fixed

Not applicable to you. Chainstack says it removed the access.

Do this

Change your Chainstack password, and change it anywhere you reused it. Rotate the node credentials you use with them, and regenerate your platform API keys.

Exploited

This is the incident itself. Attribution unknown.

Chainstack incident notice →

GitBook: an SSO flaw led to production secrets and every customer token

On 2 November an attacker used a flaw in the GitBook SSO login flow to create sessions as GitBook staff. From there they read the credentials of a misconfigured GitHub App, got into internal repositories, found a Cloudflare API key and used it to reach production secrets. GitBook took the app offline for about 16 hours to cut them off. It says the attack was aimed at one customer but treats all customer data as exposed: API tokens, integration tokens and secrets, session signing secrets and authenticated docs sites. The attacker could also act as the GitBook GitHub app and GitLab integration in the repositories each customer connected, and GitBook can't tell whether it did.

Affected

GitBook, the hosted documentation platform, including Git Sync with GitHub and GitLab.

Fixed

Not applicable to you. GitBook fixed the SSO flaw on 2 November, rotated every infrastructure secret and every secret it manages for customers, and invalidated all API tokens issued before the cutoff. It says billing information and passwords were not exposed.

Do this

Create new GitBook API tokens and update the apps that use them. Rotate any third-party tokens or secrets you connected to GitBook, and the secrets of integrations you published. If you use authenticated access with your own backend, regenerate the signing key. Re-authenticate the GitBook MCP server. Then look over recent commits and pull requests in repositories the GitBook app can reach, and search your logs for 94.183.188.91, 45.139.84.195 and 198.251.83.217.

Exploited

This is the incident itself. GitBook describes a targeted attack driven largely by automation and AI. Attribution unknown. One of its listed addresses, 94.183.188.91, is also the main address OPSSHIELD lists for the cPGuard attack in the self-hosted section.

GitBook incident post mortem →

WorkOS: CRM and support data read through an internal sales tool

WorkOS found unauthorised access to an internal application used by its sales team on 30 October. Through it the attacker read business contact details, account histories, product usage metadata, and summaries and excerpts of sales calls, support threads and customer Slack conversations. WorkOS says there is no evidence its production services or application data were touched, and that an AI-assisted offensive framework automated the reconnaissance and exploitation. Founder Michael Grinich named that framework as ARTEX.

Affected

WorkOS customers, through data held in its CRM and support tools. WorkOS says its production auth and SSO services were not accessed.

Fixed

Not applicable to you. WorkOS disabled external access to the application and brought in an outside forensics firm. The investigation is still open.

Do this

Nothing to rotate on the WorkOS side. Expect convincing phishing, because the attacker has your contact details and summaries of what you discussed with WorkOS. Confirm any unexpected request that quotes those conversations through a channel you already trust. If you ever pasted a credential into a support ticket or a shared Slack channel with WorkOS, rotate it.

Exploited

This is the incident itself. Naming the tool says nothing about who ran it. Attribution unknown.

WorkOS security bulletin →BleepingComputer report →

Trigger.dev: environment variables read for some organisations

Trigger.dev disclosed on 1 November that an attacker used an exploit to read environment variables for a subset of organisations. It says the exploit is blocked and that it emailed every affected account owner with steps to take. It has not published how the attacker got in or how many organisations were hit.

Affected

Trigger.dev, the hosted background jobs platform.

Fixed

Not applicable to you. Trigger.dev says it blocked the exploit used in the attack.

Do this

Look for the Trigger.dev email. Even without one, rotate the secrets you keep in Trigger.dev environment variables, starting with AI provider keys and cloud credentials, since stored AI keys are what this run of attacks on AI developer platforms has been after. Revoke at the issuing provider first, then update the variable, then check provider usage for spend you did not make.

Exploited

This is the incident itself. No organisation count published. Attribution unknown.

Trigger.dev security disclosure →SecurityWeek on the wider wave →

Northflank: assume every environment variable was decrypted

An attacker reached secrets held in Northflank control plane on 30 October. The company told customers to assume all environment variables had been decrypted and to rotate every key, and customers have since reported unauthorised use of the AI API keys they stored there. Northflank says running workloads and workload data were not accessed, and that forward-deployed and dedicated control planes were unaffected.

Affected

Northflank, a platform for deploying containers, databases and AI apps.

Fixed

Not applicable to you. Northflank says it contained the activity within about an hour and brought in an outside forensics firm.

Do this

Rotate every secret you had in Northflank: workload environment variables, secret groups, global secrets. Start with AI provider keys, cloud credentials, payment keys, private keys and database passwords. Revoke at the issuing provider first, then replace. Then check provider dashboards and billing for spend you did not make.

Exploited

This is the incident itself. No customer count published. Attribution unknown.

Northflank status update →

Warp: agent logs and telemetry exposed through a third-party vendor

Exploitation of a third-party vendor in Warp infrastructure exposed AI agent trace and decision logs plus user telemetry for an estimated 1% of users, a figure from CEO Zach Lloyd. Warp has not said whether prompts, source code or credentials were in those records. It engaged CrowdStrike and notified law enforcement.

Affected

Warp, the agentic terminal.

Fixed

Not applicable. The exposure came through a vendor, not Warp code.

Do this

Nothing published to rotate. Be careful with any email that quotes your Warp usage in detail, and if you pasted credentials into terminal commands you ran through an agent, rotate those.

Exploited

This is the incident itself. Attribution unknown.

Warp disclosure coverage →

Cloudflare: 155 AI responses contained other customers data

Customers sending very long prompts to the GLM-5.3 model on Workers AI got back answers containing data from other customers requests, between 27 August and 9 September. Two bugs stacked. Cloudflare set a context window of 1,048,576 tokens against a KV cache that held 681,280, and a bug in SGLang disaggregated mode passed over-length requests to the decode node anyway, which read stale cache pages and answered with HTTP 200.

Affected

The @cf/zai-org/glm-5.3 model on Cloudflare Workers AI. Self-hosted SGLang running disaggregated prefill and decode had the same bug.

Fixed

Cloudflare restored the model on 9 September. The SGLang bug is fixed in v0.5.22.

Do this

If you sent prompts longer than about 681,000 tokens to that model in those two weeks, treat both directions as exposed: your prompt may have reached someone else, and theirs may have reached you. Rotate any credential that appeared in one. If you run SGLang yourself, upgrade to v0.5.22 and check the KV pool size against the context length on every node.

Exploited

All 155 responses came from prompts over 681,280 tokens, and Cloudflare found no sign of deliberate exploitation. The request pattern looked like ordinary long-context use.

Cloudflare: KV cache exposure and remediation →

Railway: environment variables decrypted in up to 1.85% of workspaces

A campaign hunting AI provider API keys escalated through Railway build infrastructure between 20 and 22 October. It pulled secrets in encrypted form, reached the CI credentials that unlock them, and decrypted a subset of environment variables. Railway puts that at up to 1.85% of all workspaces, about 100,000, and says envelope encryption means it cannot tell you which individual keys were decrypted. User accounts were not accessed.

Affected

Railway, a cloud deployment platform. Running services stayed online, but new builds and deployments were paused and the dashboard, API and CLI had periods of downtime.

Fixed

Not applicable to you. Railway rolled its storage bucket credentials, moved to single-tenant builders and rebuilt its tooling.

Do this

Rotate every sensitive environment variable you had on Railway before 21 October and redeploy. Railway asked GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Stripe and others to revoke keys, so a revocation email from a vendor does not by itself mean your key leaked. Review GitHub audit logs, GitHub App access and registry audit logs such as Docker Hub.

Exploited

This is the incident itself. Attribution unknown; Railway names no group.

Railway preliminary report →

PingCAP: stolen service-account credentials, a month inside

Someone using valid service-account credentials was inside PingCAP internal systems from 9 September to 7 October, copying data and source code. The export includes TiDB Cloud usernames and email addresses, organisation and project associations, SQL editor text and errors, business and billing data such as contacts, contract terms, orders and pricing, and a table of encrypted API-key values.

Affected

TiDB Cloud and PingCAP internal systems. PingCAP says it has no evidence that data in customer TiDB clusters was affected.

Fixed

Not applicable to you. All identified access paths were blocked by 14 October, and four vulnerabilities the external firm reported were fixed and retested the same day.

Do this

Rotate your TiDB Cloud management API keys, review their permissions and check their access logs. Expect invoice and contract phishing that quotes real terms, because that data was in the export.

Exploited

This is the incident itself. Attribution unknown.

PingCAP security update →

Zeabur: 3.2 million environment-variable records and root on 101 servers

Cluster admin tokens sat in plaintext in a private config repo, with no expiry since January 2024, behind an admin interface reachable from the internet. An attacker used them from 14 to 15 October to read environment variable names and values across every service, run read commands inside customer database containers, and read the platform database. A second path gave root on 101 GCP dedicated servers, with SSH keys added on 50 of them.

Affected

Zeabur shared clusters in nine regions and GCP Dedicated Servers. Company figures: 3,218,965 environment-variable records, 321,810 accounts, 566 plaintext zSend API keys, read commands in 865 database services.

Fixed

Not applicable to you. Zeabur revoked the tokens and keys it knew about on 16 October. Separately, the platform shuts down on 31 December 2026.

Do this

Zeabur says act now rather than wait for an email. Change every credential in your environment variables, revoking at the provider first. Credentials you replaced after the August incident must be replaced again. Change passwords inside your databases, because changing an environment variable does not change the database password. For n8n, replace the encryption key and recreate third-party credentials.

Exploited

This is the incident itself. Attribution unknown; Zeabur labels the link to its August incident a hypothesis.

Zeabur incident report →

OpenCode: stored provider keys taken in a distillation attack

Stored API keys for 1.4% of OpenCode Console users who had linked Anthropic, OpenAI or Google were exposed, with the earliest possible access on 17 October at 00:30 UTC. Users reported unauthorised charges up to about $1,700.

Affected

OpenCode Console, the hosted tier of the coding agent.

Fixed

Not applicable to you. OpenCode notified the affected subset.

Do this

If you were in the notified group, rotate those keys at the provider and dispute the charges. Keys you used only against a local model were not in scope.

Exploited

This is the incident itself, described by OpenCode as a large-scale distillation attack.

Coverage of the OpenCode incident →

Studio: API keys and CMS data for every customer potentially exposed

Access between 30 September and 1 October, with data retrievable from outside until 14 October. Studio says data for all registered customers may be exposed: form submissions, hosted CMS content, API keys and tokens for external services, Google Sheets credentials, proxy keys and webhook URLs. The decryption key was read in the same intrusion. ITmedia puts the user base above 900,000; the company has not published a count.

Affected

Studio, a Japanese no-code site builder.

Fixed

Not applicable to you. Notices went out from 16 October.

Do this

Rotate every API key, token and webhook URL you had configured in Studio, at the issuing provider. Check the Google account you connected for Sheets access. If you published private content through it, assume the content and its access paths were readable.

Exploited

This is the incident itself. Attribution unknown.

Studio incident notice, in Japanese →

Fireworks AI: secrets injected into evaluation jobs were readable

An unauthorised third party used internal Fireworks credentials to reach environment variables used by evaluation jobs, in a limited number of customer accounts. Fireworks believes API keys and tokens stored as secrets were captured there. It says it found no access to customer models, datasets, training data, personal information, or prompt and output traffic.

Affected

Fireworks AI, a model hosting and inference platform. Affected customers were notified directly.

Fixed

Not applicable to you. Fireworks rotated employee API keys on 9 October and revoked user keys and service-account tokens on 10 October.

Do this

Fireworks keys it identified now fail authentication, so create new ones and update your apps. Rotate the third-party credentials named in your notice at the issuing provider, because deleting a secret in the Fireworks UI does not invalidate it. Then look for API keys, users, evaluators, training jobs and datasets you did not create.

Exploited

This is the incident itself. Attribution unknown.

Fireworks AI security bulletin →

Gyazo: 23.6 million user records and 490 million image records

An attacker exploited a flaw in the image upload server to run commands, then reached the database. Taken: names, email addresses, password hashes, user and device IDs, login session IDs, X integration tokens, Google SSO addresses, profile and billing status, plus image metadata including upload IP, User-Agent, EXIF location, OCR text extracted from images, titles and hashed passphrases for private images. No card data.

Affected

Gyazo, the screenshot and image sharing service. Company figures: about 23.62 million user records, of which 18.01 million are anonymous accounts, and about 490 million image-metadata records, mostly images from 2019 or earlier.

Fixed

The vulnerability was fixed on 12 September, and the affected authentication data and X tokens were invalidated.

Do this

Change your Gyazo password, and change it anywhere you reused it. Because image IDs were exposed and image URLs are built from them, treat the unguessable URL as no longer private for older images. The part worth thinking about is the OCR text: screenshots carry tokens and customer data, and that text sat next to the metadata.

Exploited

This is the incident itself. Attribution unknown.

Gyazo incident notice →Gyazo update, 25 September →

Brevo: a SAML flaw let one account reach other organisations

An attacker created an account, enabled SSO on it, and invited legitimate users. Signing in as those users granted access to every organisation they could reach rather than only the invited one. 138 accounts were accessed, six were used to send phishing to stored contacts, and contacts were exported from 43 accounts.

Affected

Brevo, the email and marketing platform.

Fixed

Brevo closed the route within two hours and signed every user out.

Do this

Nothing to install. If you use Brevo, check your contact lists for exports you did not make, and warn the people on them about phishing that appears to come from you.

Exploited

This is the incident itself. Attribution unknown.

Brevo incident write-up →

Coder registry served tampered Terraform modules for 14 hours

An attacker got a Cloudflare API key belonging to Coder and added their own IPs to the pool serving registry.coder.com. For 14 hours on 31 August, a subset of requests got tampered modules that ran a shell script during provisioning and sent credentials to coder-infra.com, a lookalike domain registered three days earlier.

Affected

Coder deployments that fetched a registry module between 07:35 and 21:45 UTC on 31 August. Coder codebase and Google Cloud infrastructure were not compromised.

Fixed

Fixed in Coder 2.37.0, 2.36.4, 2.35.7 and 2.34.9. Later releases remediate automatically.

Do this

Search firewall, proxy, DNS and VPC logs for coder-infra.com. Run the advisory SQL to find modules cached in the window, purge them, then rotate everything the provisioner could reach: cloud keys, CI credentials, SSH keys, OIDC tokens, and the Coder database password if the provisioner runs inside coderd. Coder cannot tell you whether you were affected, so you have to check.

Exploited

This is the incident itself. Attribution unknown.

Coder advisory GHSA-vx42-ghc9-gw65 →Coder incident write-up →

JetBrains Cadence was breached through an unpatched TeamCity

Unauthorised access from 8 to 24 August, found on 23 August, service taken offline on 24 August. Taken: usernames, real names, email addresses, login timestamps and IPs, a full Cadence server backup from 2024, and the AWS IAM user credentials in that backup. JetBrains warns that source code synced from PyCharm to the server may have been accessed, and that all executions should be treated as untrusted.

Affected

JetBrains Cadence, the cloud compute service behind the PyCharm plugin. The service is now shut down.

Fixed

Cadence ran a TeamCity vulnerable to CVE-2026-63077, which JetBrains had already fixed in its own product. Taking the service offline ended the access, and Cadence plugin tokens were invalidated.

Do this

If you used Cadence, revoke and rotate every credential you used to run executions, and follow what they could reach: AWS accounts, buckets, deployment environments, registries. Review repositories for changes from 8 August.

Exploited

Yes. The entry point was TeamCity CVE-2026-63077, which is on KEV and used in ransomware campaigns. Attribution for the Cadence intrusion itself is unknown.

The TeamCity flaw is in the Open source section.

JetBrains Cadence incident notice →Coverage in The Hacker News →

Metabase Cloud: a zero-day took attackers into customers databases

An unauthenticated SQL injection let an attacker create a session and become an admin on a customer Metabase instance, then steal the stored credentials for every connected database and read the data behind them. Metabase says under 3% of Cloud customers were compromised before patching. Framework, Tally, Kilo Code and Beacon have since disclosed data theft downstream.

Affected

Metabase Cloud, and self-hosted Metabase 0.58 and later.

Fixed

Cloud instances were patched automatically. Self-hosted fixes are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5.

Do this

Upgrade, then revoke all active sessions, review API keys and admin accounts, and rotate the credentials for every database Metabase can reach. Rotating the Metabase admin password is not the fix; the connected data sources are. If you are triaging old logs, the signature is a POST to the password reset endpoint returning 400 followed by a successful GET to /api/user/current from the same client.

Exploited

Yes. Metabase Cloud was attacked with it before a public patch existed, and CISA added the CVE to KEV on 11 August.

The same flaw in self-hosted installs is in the Open source section.

Metabase: what happened →Metabase security update →

RingCentral: social engineering, and 1.6 million accounts in a leak

RingCentral describes a sophisticated social engineering campaign and says it stopped the activity when it detected it. The ShinyHunters group claimed the intrusion and published an archive after no payment. Have I Been Pwned, analysing that archive, counted 1.6 million accounts with names, email addresses, phone numbers and physical addresses. RingCentral has published no count of its own and says a limited portion of customers were affected.

Affected

RingCentral cloud communications, used by more than 600,000 businesses. The record count is disputed between the company and HIBP.

Fixed

Not applicable to you. RingCentral says it remediated the access and engaged outside forensics.

Do this

RingCentral position is that customers it has not contacted are not affected. If your contact data is in the leak, expect phishing and voice phishing that quotes real names, numbers and reporting lines.

Exploited

This is the incident itself. The 623GB and 280GB figures are the attacker claims, not confirmed by the company.

RingCentral security bulletin →Coverage of the leak analysis →

webhot.dk was rebuilt from scratch after ransomware

A small Danish host taken offline by ransomware and rebuilt from nothing. Email was restored on 17 July, but everything received before the rebuild was lost for good and customers had to recreate their accounts.

Affected

webhot.dk customers. No count published.

Fixed

Not applicable. The provider rebuilt rather than restored.

Do this

The reader action is the same for any host: keep your own copy of mail, sites and databases somewhere else, and test that you can restore it. Reported by Computerworld Denmark.

Exploited

Ransomware. Attribution unknown.

Computerworld Denmark report →

Grok Build was uploading whole Git repositories, history included

A researcher captured the Grok Build CLI 0.2.93 uploading entire repositories, tracked files plus full commit history, to a storage bucket on a channel separate from model traffic. On a 12GB repository the model never read, model traffic was about 192KB while the storage channel moved 5.10GiB. A canary file explicitly excluded from the task came back verbatim, and a tracked .env the agent read went into the model turn unredacted.

Affected

Grok Build CLI 0.2.93. No user count disclosed. The shutoff was a server-side flag on 13 July, not a client fix.

Fixed

Server-side upload disabled on 13 July, and previously uploaded data was to be deleted. The training opt-out did not control this: the settings endpoint kept reporting trace upload enabled with it off.

Do this

If you ran Grok Build, rotate every credential that was in a tracked file or anywhere in Git history, because a secret you committed and later deleted still rode along. Consumer subscribers can run /privacy in the CLI to disable retention and delete synced data.

Exploited

This is not an intrusion. The tool uploaded code by design, and the design was wrong. Attribution not applicable.

The Hacker News report →Cybernews report →

Klue: one stale credential and a cascade through customers Salesforce

An attacker used a long-disused but still active credential from an abandoned prototype integration to reach Klue integration infrastructure, then took the OAuth tokens Klue held for its customers and used them to query and exfiltrate data straight from customers Salesforce instances. Confirmed affected organisations include LastPass, Huntress, BeyondTrust, 8x8, Pendo, HackerOne, Jamf, OneTrust, Recorded Future, Snyk, Sprout Social, Tanium and Gong.

Affected

Klue, a market-intelligence platform, and its customers connected CRM environments. No customer count from Klue.

Fixed

Not applicable to you. Klue revoked the credentials and tokens, removed unauthorised code, and disabled integrations including Salesforce, HubSpot, SharePoint, Zoom, Gong and Slack. Salesforce disabled the Klue Battlecards integration.

Do this

Revoke any OAuth tokens and connected-app grants Klue held, and review Salesforce event logs for query activity from IPs you do not recognise. The exposure is in your CRM, not your product. Expect follow-on phishing and extortion that quotes real deal data.

Exploited

This is the incident itself. Klue did not name an actor. Huntress says it has high confidence the Icarus extortion group was responsible, which is the firm assessment, not the victim statement.

Klue incident update →Huntress investigation →

ServiceNow: an unauthenticated API endpoint used to query customer instances

ServiceNow applied a security update to hosted instances that limited an API endpoint to authenticated users. The company confirmed attackers had exploited the flaw and successfully queried customer instance tables. Administrators discussing it publicly pointed at /api/now/related_list_edit/create, apparently configured with authentication not required; that detail is from administrators, not from ServiceNow.

Affected

ServiceNow hosted instances, primarily on the Australia platform release or older releases with certain configuration changes.

Fixed

The update was applied on 5 June. ServiceNow opened support cases with affected customers.

Do this

Review instance logs for requests to that endpoint, particularly from 51.159.98.241, an indicator shared by administrators. Treat anything stored in tickets as potentially read, and rotate any credential that was pasted into a support case.

Exploited

Yes, per ServiceNow. It characterises the activity as likely tied to security researchers or bug bounty work rather than malicious actors, after receiving a related bug bounty report on 22 April.

Coverage of the ServiceNow incident →

GitHub: around 3,800 internal repositories taken through a poisoned VS Code extension

An employee device was compromised by a malicious build of Nx Console 18.95.0, which sat on the Visual Studio Marketplace for about 18 minutes. It harvested Vault tokens, npm and OIDC tokens, AWS credentials, GitHub tokens and SSH keys from disk and memory. Around 3,800 GitHub internal repositories were exfiltrated. GitHub says the attacker claim of 3,800 is directionally consistent with its investigation, and that it found no impact to customer repositories.

Affected

GitHub internal repositories. GitHub Enterprise Server administrators had a signing key to replace; GitHub Enterprise Cloud customers had nothing to do.

Fixed

Fixed in Nx Console 18.100.0. GitHub rotated the GPG public key that signs GHES packages.

Do this

If any developer machine ran Nx Console 18.95.0, rotate every credential reachable from it and check for ~/.local/share/kitty/cat.py and the com.user.kitty-monitor launch agent on macOS. GHES administrators must rotate the GPG key with GitHub published script, or future upgrades fail signature verification.

Exploited

This is the incident itself. GitHub did not attribute it; the TeamPCP group claimed it on a criminal forum.

The malicious extension came out of the TanStack npm compromise in the Open source section.

GitHub investigation →Nx Console advisory →

Braintrust: an AWS account holding customers AI provider keys was accessed

Unauthorised access to an internal AWS account used by Braintrust systems, which held API keys that customer organisations use to reach AI models. At least one customer confirmed affected, with three others reporting suspicious spikes in AI provider usage. Braintrust notified every organisation admin with stored provider secrets.

Affected

Braintrust, an AI evaluation and observability platform.

Fixed

Not applicable to you. Braintrust locked down the account, audited access across related systems and rotated internal secrets.

Do this

In org settings, delete or revoke the existing AI provider secrets, add new ones, and confirm the rotation by checking timestamps. Then check each provider usage and billing from 4 May onward.

Exploited

This is the incident itself. Braintrust told TechCrunch it had confirmed a security incident but saw no evidence of a breach, while its customer email asked everyone to rotate keys. The advice follows the email.

SecurityWeek report →TechCrunch report →

Node.js: security releases for 22, 24 and 26 due on 11 November

The Node.js project announced on 4 November that it will release new versions of the 22.x, 24.x and 26.x lines on or shortly after 11 November to fix security vulnerabilities. The highest severity in each line is high. The details come out with the releases.

Affected

Node.js 22.x, 24.x and 26.x. End-of-life versions are always affected and get no fix.

Fixed

Not yet. The releases are due on or shortly after 11 November.

Do this

Plan to upgrade and redeploy that week, and rebuild container images that bundle Node. If you still run an end-of-life line, move to 22, 24 or 26 now, so next week is a patch bump. The nodejs-sec mailing list announces the release.

Exploited

Unknown. The vulnerabilities are not public yet.

The Brotli out-of-bounds write Node.js fixed earlier is further down this section.

Node.js pre-alert →Node.js on X →nodejs-sec mailing list →

cPGuard: a poisoned update took password hashes and SSH keys from servers

An attacker got into OPSSHIELD, the company behind the cPGuard server security tool, and pushed a malicious script through its update channel on 2 November. Versions 5.88.12 to 5.88.19 carried it. The script left a setuid root shell at /var/tmp/.cpg91511_sh plus a cron entry, and collected /etc/shadow, /etc/passwd, root SSH files, the MySQL root config in /root/.my.cnf, root shell history and, on some servers, /root/.s3cfg. OPSSHIELD later said about 2,950 servers ran it. The way in was its billing and licensing server, reached from a trial account the attacker signed up for on 1 November, and billing records for about 7,900 customer accounts were taken too.

Affected

Servers running cPGuard that updated to any version from 5.88.12 through 5.88.19 on 2 November. Check with grep "Successfully updated" /opt/cpguard/logs/install_log. A missing log does not mean you are clear.

Fixed

OPSSHIELD first named 5.88.25 as the fix. Its later disclosure says 5.88.26 removes the backdoor and a separate follow-up update removes the cron entry, so install the latest version.

Do this

Run cpgcli update --start, then cpgcli --version. Check that /etc/cron.d/i93677, /var/tmp/.i93677/ and /var/tmp/.cpg91511_sh are gone. If the log shows an affected version, treat the server as compromised even after updating: reset root and every local password from a trusted recovery environment, change the MySQL root and database passwords, rotate S3 and DigitalOcean keys and anything in root shell history, and replace the keys in /root/.ssh everywhere they are trusted. Every OPSSHIELD customer should also reset the billing portal password and turn on two-factor login.

Exploited

Yes, this is the attack itself. OPSSHIELD confirmed the attacker retrieved collected files. Attribution unknown. The main attacker address it lists, 94.183.188.91, also appears in the GitBook indicators.

OPSSHIELD advisory →The Hacker News, with the later disclosure →

WordPress: a race in the core upgrade, after a template flaw in September

Two separate unauthenticated code-execution paths in WordPress core within five weeks. CVE-2026-119977 is a race during a full-package core upgrade, where files are staged at predictable web-accessible paths, so an attacker can run code during the upgrade window. CVE-2026-87902, fixed in September, let get_page_template() include a readable local .php file outside the theme, which became RCE when the theme directory starts with page- and something like pearcmd.php is readable.

Affected

CVE-2026-119977: WordPress 4.7 through 7.1.3. CVE-2026-87902: essentially every supported branch from 4.7.0 to 7.1.1.

Fixed

WordPress 7.1.4, released 28 October, contains both fixes. Backports for 119977 were still shipping when the advisory went out, so the number to install is 7.1.4.

Do this

Update to 7.1.4 from the dashboard or let automatic updates run. There is no config toggle that removes the upgrade race. On the September flaw, the exploit was conditional on the theme and a readable PHP file, but the fix is the same. Check for administrator accounts you do not recognise.

Exploited

Yes, both. CISA added CVE-2026-87902 on 25 September and CVE-2026-119977 on 3 November. WordPress enabled forced automatic updates for the affected versions.

WordPress 7.1.4 release →Advisory for CVE-2026-87902 →Tenable record for CVE-2026-119977 →

Linux kernel: page-cache writes that chain with the PHP bugs

skb_try_coalesce() could move page-cache-backed fragments into a socket buffer without the shared-fragment marker, so ESP input processing decrypted them in place and modified page-cache data. CISA describes the chain directly: this plus the two October PHP bugs is how an attacker implants a PHP webshell. NVD scores it 7.8.

Affected

Linux kernels that include the affected coalescing path. Red Hat lists every supported Enterprise Linux branch among the affected products, which is a fair proxy for the rest of the distributions.

Fixed

A kernel update from your distribution. There is no single upstream version number to quote: take the kernel your distro has patched and reboot into it. The upstream fix is titled net: skbuff: preserve shared-frag marker during coalescing.

Do this

Update the kernel package and reboot. Then patch PHP, because these two are designed to be used together. If you cannot reboot yet, keep PHP patched and watch for unexpected files in your web roots.

Exploited

Yes. CISA added it to KEV on 28 October, and its own description names the PHP chain.

The PHP bugs are in this section too, and the two are used together.

NVD record for CVE-2026-46300 →CISA KEV catalog →

Magento and Adobe Commerce: PolyShell uploads, now in KEV

CVE-2026-48356, which Sansec named PolyShell, is an unrestricted file upload that lets attackers drop PHP webshells disguised as images on a store. Sansec reported it as a mass attack in March, when one operator put a JavaScript loader into the CMS blocks of 471 stores in one hour. Its October report counts 953 stores hit by that campaign since July 2025, mostly Magento, with the loader now fingerprinting visitors to hide from scanners. Adobe scores the bug 9.6 and says no authentication is needed.

Affected

Magento Open Source 2.4.9, 2.4.8-p5 and earlier, 2.4.7-p10 and earlier, 2.4.6-p15 and earlier. Adobe Commerce 2.4.9 and the 2.4.4 to 2.4.8 lines up to their latest -p releases, Commerce B2B, and Commerce Events 1.6.0 to 1.20.0.

Fixed

Adobe bulletin APSB26-73 from 14 July: Magento Open Source 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul or 2.4.6-2026-jul, the matching -2026-jul releases for Adobe Commerce 2.4.4 to 2.4.9, and Commerce Events 1.21.0.

Do this

Install the July release for your branch. Then check whether you were already hit: run find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name .htaccess and find . -name accesson.php -type f, search cms_block and cms_page for fpCode, se_referrer or localStorage.getItem, and look in admin_user for accounts you do not recognise. If you find anything, clean it up and change the database, admin and API integration passwords. Patching alone does not remove a loader that is already in your database.

Exploited

Yes. CISA added it to KEV on 27 October, months after the March attacks. Adobe bulletin still says it is not aware of exploits in the wild. Sansec tracks it as one criminal campaign; nobody has named the operator.

Adobe bulletin APSB26-73 →NVD record for CVE-2026-48356 →Sansec research →

PHP: two memory bugs let one request run code on the web server

PHP fixed two memory-handling bugs that allow unauthenticated remote code execution in any installation serving web requests. CVE-2026-109618 abuses the out-of-memory longjmp() path so request shutdown processes half-built state, and CVE-2026-109619 lets a later request on the same worker use stale pointers to freed memory. Both are CVSS v4.0 9.2, and both were on CISA KEV within five days. A third bug, CVE-2026-115560, disclosed on 23 October, affects even fully patched releases and needs an unusual runtime change of session.serialize_handler; use the session.upload_progress setting below until the next regular release.

Affected

PHP 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36, 8.2 before 8.2.35. Applies to PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP 8.1 and older get no upstream fix, only minimal source backports.

Fixed

8.5.12, 8.4.27, 8.3.36 and 8.2.35, released 21 October. Restart every worker after upgrading.

Do this

Upgrade and restart. If you cannot yet: set session.upload_progress.enabled = 0 in php.ini or the FPM pool, and on 8.5 set fatal_error_backtraces = 0. Block multipart request bodies at the proxy if you accept none. PHP says plainly that only updating is a complete fix, and that mod_php is the highest-risk configuration because the demonstrated exploit fires before any application code runs.

Exploited

Yes. CISA added both CVEs to KEV on 26 October. The public exploitation is demonstrated against mod_php; FPM is assessed as vulnerable from source analysis, without a complete public exploit, so do not treat FPM as safe but do not repeat the claim that it is fully demonstrated either.

PHP advisory GHSA-w8hw-w9fx-j79w →PHP release archive →CERT-EU advisory 2026-018 →

Brotli: an out-of-bounds write inherited by Node.js

An invalid block switch in Brotli decompression is treated as need more input instead of a format error, so the streaming decoder keeps appending into an eight-byte buffer and writes past it. Node.js bundles its own copy, so any Node service that decompresses attacker-supplied Brotli data is exposed. Per Node.js the impact is corrupted process memory: a crash, disclosure of process memory, or remote code execution.

Affected

Brotli 1.0.3 before 1.0.10, 1.1.0 before 1.1.1, 1.2.0 before 1.2.1. Node.js 22.x, 24.x and 26.x at the time. Also reported affected: .NET, PowerShell 7, Visual Studio, Git for Windows, Bun, Envoy, Istio, the Python brotli and brotlicffi packages, and PHP Windows builds.

Fixed

Brotli 1.0.10, 1.1.1 or 1.2.1. Node.js 22.23.4, 24.22.1 and 26.12.1. .NET 8.0.33, 9.0.22 and 10.0.14. PHP Windows builds ending in -1.

Do this

Upgrade and redeploy, and rebuild container images, because the vulnerable copy is compiled into the runtime. Node.js offers no workaround. Where you cannot patch, stop accepting Brotli-compressed input from untrusted sources.

Exploited

Yes, per CISA KEV on 27 October. Public exploit traffic has been reported against Node 24.22.0, but the demonstrated impact so far is mostly crashes, with code execution in a narrow configuration.

Node.js security releases, October 2026 →Canadian Centre for Cyber Security alert AL26-027 →

LiteLLM 1.107.0: a poisoned release that runs on any Python start

Attackers published a malicious 1.107.0 to PyPI and to the official container registries. It drops cook.pth, cook.py and sitecustomize.py into site-packages, so Python own startup runs the payload whether or not you import LiteLLM. The collector targets Git credentials, npm config, .env files, cloud credentials and instance metadata, Kubernetes service-account tokens, SSH keys, Vault and CI config, browser stores, other processes environments, and selected credential rows from the proxy database.

Affected

litellm==1.107.0 on PyPI, all seven wheels, live 11:39 to 13:23 UTC. Docker Hub and GHCR tags v1.107.0, latest, main-latest and main-stable until 14:20 UTC. The 1.107.0 source tag on GitHub is clean: the malicious artifacts were built from an attacker-controlled lookalike repo.

Fixed

There is no fixed 1.107.0. Pin 1.106.2 or an earlier explicit version, or a later release. LiteLLM re-signed from 1.103.8, 1.104.6, 1.105.4 and 1.106.3 on 24 October with a new signing key.

Do this

Do not start Python or pip in a suspect environment, because that re-runs the payload. From a clean machine, delete cook.pth, cook.py, sitecustomize.py and matching __pycache__ files from every site-packages, kill the detached loader process, then rebuild from pinned artifacts. Rotate everything the host could reach: instance IAM role, every provider key in the proxy database plus master and virtual keys, the database URL, and anything in a process environment. Check CloudTrail for GetCallerIdentity from the instance role around install time.

Exploited

This is a supply-chain compromise rather than an exploited vulnerability. The package was public for about two hours, and no confirmed victim has been reported. Say compromised and pulled, not thousands affected.

LiteLLM incident post →Microsoft technical analysis →

Plex Media Server: four chained bugs, then miners and proxies

1.43.3 shipped on 1 September, and the warning about active exploitation came on 19 October. Four flaws chain into unauthenticated remote code execution. An SSRF in the player timeline endpoint plus access to internal agent functions over loopback discloses the server owner admin token, and the token unlocks a transcoder preference that writes an arbitrary file into the Codecs directory, which is loaded on the next transcode. Plex says compromised servers are being used to run cryptocurrency miners and proxy software.

Affected

Plex Media Server 1.43.2 and earlier.

Fixed

1.43.3.10861 and later. NAS users may have to install the package by hand if their app store lags.

Do this

Update. If the server was reachable from the internet while on an older build, assume compromise: look for unfamiliar processes (Plex names myawesomeproxy, mylovelyminer and x12345), unfamiliar .so or .dll files in the Codecs folder, and outbound connections to proxystream.st. Plex guidance is to rebuild from a clean install rather than reuse the data directory, clear the Codecs folder, sign out all devices and change the password. If you do not need remote access, turn it off and do not forward port 32400.

Exploited

Yes. Plex states the flaws are being actively and widely exploited, and CISA added all four to KEV on 20 October. Plex publishes no victim count.

Plex security update →

OVHcloud CLI: release binaries replaced with a credential stealer

On 19 October, between 14:47 and 16:21 UTC+2, someone using an OVHcloud developer GitHub account replaced the release binaries of ovhcloud-cli v0.11.0 to v0.15.0 with a build that steals credentials. The source code and the build chain were not touched, only the files attached to the GitHub releases. Only installs and updates in that window are affected, around 250 downloads. OVHcloud traced the account compromise to a VS Code extension installed a year earlier on a personal Mac, and links the payload to a group it calls Glassworm through the wallet the samples call.

Affected

ovhcloud-cli v0.11.0 to v0.15.0, downloaded between 14:47 and 16:21 UTC+2 on 19 October 2026. v0.10.0 and earlier are clean, and so is v0.16.0 and later. The advisory lists an MD5 hash per platform, so you can check the binary you have without running it.

Fixed

v0.16.0, published with a signed tag the same evening.

Do this

If you installed or updated the CLI in that window, treat the machine as compromised and change what it could reach: AWS, GCP and Azure credentials, Docker and Kubernetes config, npm, Terraform, doctl, .netrc and SSH keys. The stealer also copies the VS Code, Cursor, Continue, Cody, OpenCode, Hermes and Claude stores, so those sessions went with it. Check your temp folder for a directory named envchecker- followed by digits, which the payload leaves behind, then reinstall at v0.16.0.

Exploited

This is the incident itself. OVHcloud links the tooling to a group it calls Glassworm and publishes no other attribution.

OVHcloud advisory GHSA-862f-55f5-vmvw →

BeyondTrust Remote Support: authentication bypass on self-hosted appliances

Improper origin validation in Remote Support internal messaging let a remote, unauthenticated attacker perform file operations on the appliance, CVSS v4.0 9.3. CISA describes the observed post-exploitation as establishing persistence, escalating privileges and moving laterally; Mandiant tracks the activity as ARMORY CASTLE.

Affected

All Remote Support versions up to 26.2.3.

Fixed

Patch BT26-05-RS for versions 24.3.1 through 26.2.3, or Remote Support 26.3.1 and later. Below 24.3.1 you have to upgrade before the patch applies.

Do this

Patch, or upgrade to 26.3.1. Then treat the appliance as suspect: network and memory forensics, rebuild from a known-good state, rotate every credential it stored or injected, revoke all active support sessions, and review new MFA registrations on privileged accounts.

Exploited

Yes. CISA says threat actors are actively exploiting it and added it to KEV on 16 October. BeyondTrust describes the impact as file operations, not remote code execution, so read it that way.

BeyondTrust advisory BT26-05 →CISA alert →

Ivanti Connect Secure: a zero-day chain to root, on patched appliances

Three chained bugs gave an unauthenticated attacker root on a fully patched VPN appliance. CVE-2026-104935 is the authentication bypass and initial code execution; CVE-2026-111357 escalates to root by patching an Ivanti library in memory so the privileged service runs attacker code; CVE-2026-118527 is the third. In the observed intrusion the attacker took domain and LDAP credentials, queried Active Directory for LAPS passwords and BitLocker recovery keys, and ran password spraying, without leaving a web shell.

Affected

Connect Secure 25.1.1.2 and prior, 25.1.2.2 and prior, and 22.8R2.5 and prior. The Volexity case was a device on 22.8R2.4, the latest build at the time.

Fixed

Upgrade to 25.1.1.3 or 22.8R2.6. The 13 October fixes in 25.1.1.2 and 22.8R2.5 do not remediate CVE-2026-111357 or CVE-2026-118527.

Do this

Patch, then assume compromise if the appliance was internet-facing and unpatched. Ivanti Integrity Checker Tool will not detect this, because the library patch exists only in memory and the logs are selectively truncated. CISA recovery path: back up the config, factory reset or rebuild, upgrade, restore the config, then reset all domain, admin and local passwords and reissue certificates and API keys.

Exploited

Yes. Volexity documented in-the-wild exploitation by an actor it tracks as UTA0576, from 3 October. CISA confirms credential theft and data exfiltration. Attribution beyond that name is unknown; Volexity assesses with low confidence that the actor is criminal rather than espionage. CVE-2026-111357 severity is disputed: the CVE record and Rapid7 score it 7.0, Ivanti scores it 8.8.

Volexity analysis →CISA alert →Rapid7 analysis →

GitLab: unauthenticated RCE in the CI/CD regex compiler, CVSS 10.0

A crafted regular expression in a CI/CD configuration lets an unauthenticated user run arbitrary code on a self-managed GitLab server, through insufficient regex validation. GitLab shipped six threat-detection rules for self-managed instances, which tells you what exploitation looks like: Onigmo worker crashes and CI lint worker crashes.

Affected

GitLab CE and EE 19.2 before 19.2.8, 19.3 before 19.3.5, 19.4 before 19.4.2. CVSS 10.0.

Fixed

19.2.8, 19.3.5 and 19.4.2. The fix is not entirely in GitLab code: the integer overflow is in Onigmo, the regex engine inside Ruby, so if you build GitLab yourself or bring your own Ruby you also need Ruby 3.3.13, 3.4.12 or 4.0.9.

Do this

Upgrade with GitLab official packages, Helm chart or image, and patch Ruby too if you supply it. Alpine rebuilt its whole instance from scratch because it upgraded GitLab but was still running stock Ruby. If you cannot patch, disable open sign-up and stop untrusted users writing to public projects, which blocks the delivery path but not the bug.

Exploited

Yes, per CISA KEV on 29 October. Alpine Linux documented an attacker registering an account and sending crafted CI configs, crashing workers eight times and getting partway through the exploit on four occasions. It found no evidence code ran but could not rule it out.

GitLab patch release 19.4.2 →Alpine Linux incident report →

Two npm packages republished with credential-stealing worms

@subql/[email protected] and [email protected] went out with malicious install hooks after attackers took over maintainer access, one through a tampered CI workflow and one through a compromised account. Both harvested cloud, registry and AI-provider credentials, and both tried to spread. The tensorlake payload also installs a service called gh-token-monitor that deletes the user home directory if the stolen GitHub token is revoked.

Affected

@subql/common exactly 5.8.3. tensorlake exactly 0.5.144 plus six platform packages at that version. PyPI and crates.io builds were not affected.

Fixed

@subql/common 5.8.2 is the last known clean version. tensorlake 0.5.143, or 0.5.145 if it has been published.

Do this

Treat any machine or runner that installed these as compromised and rotate from a clean host. For tensorlake, remove the monitor service before revoking any GitHub token: systemctl --user disable --now gh-token-monitor.service, then delete ~/.config/gh-token-monitor/ and ~/.local/bin/gh-token-monitor.sh. Check lockfiles and caches, and look for the workflow branch dependabot/github_actions/format/setup-formatter in repositories your tokens could write to.

Exploited

Yes, these are malicious publications rather than vulnerabilities. Tensorlake says its own SDK telemetry showed no use of 0.5.144, which is a vendor claim about telemetry, not proof nobody installed it.

StepSecurity analysis of SubQuery →Tensorlake advisory GHSA-8g63-53c9-65j2 →

Atlassian Data Center: unauthenticated file read, exploited within hours of a PoC

A path traversal in the shared web-resource library let unauthenticated attackers read specific files inside the application web root, across eight self-hosted products, if they knew the exact name and path. There is no directory listing. The dangerous target is WEB-INF/classes/crowd.properties, which can hold plaintext application credentials; with Crowd reachable, those credentials allow creating a Jira administrator through Crowd API. CVSS 9.3.

Affected

All versions before the fixes below, for Bitbucket Data Center, Confluence Data Center, Jira Software and Jira Service Management Data Center, Bamboo Data Center, Crowd Data Center, Crucible and Fisheye. Atlassian Cloud was already patched.

Fixed

Bitbucket 9.4.26, 10.2.8, 10.5.1. Confluence 9.2.26, 10.2.19. Jira Software and JSM 9.12.40, 10.3.26, 11.3.12. Bamboo 10.2.24, 12.1.12. Crowd 6.3.7, 7.0.3, 7.1.7, 7.2.4. Crucible and Fisheye 4.9.15.

Do this

Patch. If you cannot, Atlassian publishes three options: take the instance off the internet; a WAF regex blocking .. next to /, a backslash or ::; or Tomcat rewrite rules per product. Check access logs with up to two URL-decoding passes. Crowd should not be reachable from the internet in any case, and an IP allowlist makes the escalation much harder.

Exploited

Yes. Honeypots saw attempts within two hours of the public proof of concept, and CISA added it to KEV on 15 October. Atlassian says it cannot confirm whether individual customer instances were compromised, and that Cloud showed no evidence of exploitation.

Atlassian advisory →Coverage of exploitation after the PoC →

Citrix NetScaler: unauthenticated command injection in the default configuration

CVE-2026-88771 is improper input validation leading to unauthenticated arbitrary command execution, and it affects all ADC and Gateway deployments in the default configuration, with no extra feature required. CVE-2026-88772 is a memory overflow leading to RCE or denial of service in DTLS configurations, on by default on VPN vServers. CISA notes attackers can chain CVE-2026-88779 to force a reboot and accelerate execution of code already injected.

Affected

NetScaler ADC and Gateway. 14.1 before 14.1-73.37, 13.1 before 13.1-64.23. A separate September round, CVE-2026-19490, is an authentication bypass on Gateway and AAA vServers with a SAML action.

Fixed

14.1-73.37, 13.1-64.23, plus the FIPS builds 14.1-73.37 FIPS and 13.1-37.279. For CVE-2026-19490, 14.1-73.32 and 13.1-63.21.

Do this

Check for compromise before you patch, because CISA warns that updating reduces forensic visibility. Preserve and forward logs off the box, then upgrade. If it was compromised, restore a backup predating the intrusion and rotate local account passwords, key-encryption keys and SSL certificates.

Exploited

Yes. Citrix states exploitation of 88771 and 88772 has been observed on unmitigated deployments, and CISA received reports of global active exploitation. CISA added CVE-2026-88772 to KEV on 27 September, and CVE-2026-19490 on 9 September.

Citrix bulletin CTX697096 →CISA alert →

GitLab: unauthenticated arbitrary file read, CVSS 10.0

Improper path confinement and missing authentication enforcement in the repository commits API let an unauthenticated attacker read arbitrary files from the GitLab server: gitlab.yml, secrets, runner tokens, whatever the process can read.

Affected

GitLab CE and EE from 18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6, 19.3 before 19.3.2.

Fixed

19.3.2, 19.2.6 and 19.1.8, with backports in 19.0.9 and 18.11.12. GitLab.com and GitLab Dedicated were already patched.

Do this

Upgrade. GitLab published three detection rules for the attempts: local file inclusion reading gitlab.yml, inclusion through the metadata.path parameter, and general file-path attempts. If you see hits, rotate the secrets in gitlab.rb and gitlab.yml and rotate runner tokens.

Exploited

Yes. CISA added it to KEV on 11 September, and GitLab own release notes say so.

GitLab patch release 19.3.2 →

Starlette: a malformed Host header defeats path-based auth

A Host header containing /, ? or # makes request.url.path disagree with the path actually routed. Middleware and endpoints that make security decisions on request.url rather than the raw ASGI path, such as auth gates, admin path checks and allowlists, can be bypassed.

Affected

PyPI starlette up to and including 1.0.0. That means FastAPI apps on the affected range, and anything else built on Starlette.

Fixed

Starlette 1.0.1, which shipped quietly in a routine release on 21 May.

Do this

Upgrade to 1.0.1 or later. On FastAPI before 0.133.0 the dependency pins starlette<1.0.0, so pip install -U starlette cannot reach the fix; upgrade FastAPI first. If you cannot, make sure any path-based access control reads request.scope["path"] and not request.url.path.

Exploited

Yes. CISA added it to KEV on 2 September, months after the quiet fix.

Advisory GHSA-86qp-5c8j-p5mr →Starlette release notes →

JFrog Artifactory: three flaws chained to admin, with backdoors that survive patching

CVE-2026-42018 returns an internal anonymous-user token to unauthenticated callers even with anonymous access disabled. CVE-2026-42016 does not validate token scope for privilege escalation. CVE-2026-82329 gives unauthenticated admin access under the default configuration. With them, two unauthenticated HTTP requests go from nothing to an admin-scoped token, then to persistent admin accounts, a malicious Groovy plugin for code execution, a Rust backdoor, and the Access signing key, which lets an attacker mint valid tokens for any user indefinitely.

Affected

Self-hosted Artifactory. Cloud is already protected. CVE-2026-82329 affects 7.111.4 through 7.111.21, 7.117.0 through 7.117.27, 7.125.0 through 7.125.19, 7.133.0 through 7.133.28, 7.146.0 through 7.146.36 and 7.161.0 through 7.161.19.

Fixed

7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 and 7.161.20. For CVE-2026-42016 alone, 7.133.11. If you cannot move fast on 82329, add a random additionalJoinKeys value under shared then security in system.yaml and restart Access.

Do this

Patch, then hunt anyway. Wiz found attacker admin accounts and Groovy plugins that survive the upgrade, and the stolen signing key survives it too. Check for accounts named Nxploited_*, labadmin_*, svc_*, jfrog-* and repo-service, and for files in $JFROG_HOME/var/etc/artifactory/plugins/. If a plugin is present, reset the token certificate rather than just upgrading.

Exploited

Yes. Wiz confirmed in-the-wild exploitation of all three. KEV dates: CVE-2026-82329 on 2 September, and CVE-2026-42016 and CVE-2026-42018 on 11 September.

JFrog security advisories →Wiz analysis of the in-the-wild exploitation →

crates.io: arrayref republished with a build-time downloader

[email protected] was published with a dependency on proc-macro1, a typosquat of proc-macro2 whose build script downloaded a malicious payload. [email protected] and [email protected] were republished the same way. The malicious arrayref version was live for 86 minutes.

Affected

[email protected], [email protected], [email protected], plus the malicious crates proc-macro1, proc-macro-en, aovine, arone, aronenao and tinymember at any version.

Fixed

Not applicable: the malicious versions were removed from the registry the same day and the maintainer account is locked. Pin the previous version of each crate.

Do this

Search your cargo cache for the affected tarballs, then check Cargo.lock and any vendored registry copies. The Rust blog gives the exact find command. If you built with them, rotate every credential reachable from that build. Turn on a minimum-release-age cooldown if your toolchain supports it.

Exploited

Unknown. The Rust Security Response Team describes a malicious crate, not observed victims. It says the arrayref author was probably acting in good faith and their machine or credentials were likely compromised. Attribution unknown.

Rust blog: supply-chain attack on arrayref →JFrog research →

Metabase: unauthenticated SQL injection to admin, exploited as a zero-day

An unauthenticated SQL injection on the password reset endpoint let an attacker become an administrator of a self-hosted Metabase, then change configuration and read the stored credentials for every connected database.

Affected

Self-hosted Metabase 0.58 and above. Below 0.58 is not vulnerable.

Fixed

0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 and 0.63.5, the minimum safe release on each line.

Do this

Upgrade, then if the reset endpoint was publicly reachable: delete all rows in core_session, review and delete unknown API keys, review admin accounts, rotate every connected database credential, and check the warehouse logs. The attack signature is a POST to /api/session/reset_password returning 400 followed by a GET to /api/user/current returning 200 from the same client.

Exploited

Yes. It was used against Metabase Cloud from 31 July and self-hosted instances were attacked too. CISA added it to KEV on 11 August.

Metabase security update →Metabase: what happened →

ChainDrop: a self-propagating npm worm across hundreds of packages

A Bun-based credential stealer ran through an npm preinstall hook before installation finished. It authenticated with stolen npm, GitHub, AWS, Kubernetes and Vault credentials, enumerated what each identity could reach, and republished every package the stolen npm token could publish, bumping the patch version. It also injected Claude and VS Code config files into repositories as a developer-to-developer infection path.

Affected

More than 400 packages across unrelated publishers, including keyv, flat-cache and cache-manager. The counts are reported differently: Microsoft says more than 400 packages, an OpenSSF report covering the same wave lists 444 packages and 2,234 malicious versions. Treat both as approximate.

Fixed

Not applicable: the malicious releases were pulled and clean versions republished. Microsoft guidance is to pin known-good versions and move to npm CLI v12 with min-release-age.

Do this

Treat any workstation or runner that installed an affected package with lifecycle scripts enabled as compromised. Purge npm and yarn caches, review lockfiles and CI caches, rotate npm, GitHub, cloud and Vault credentials from a clean machine, and audit for npm publishes you did not make. ignore-scripts in CI would have stopped every infection here.

Exploited

This is the attack itself, not a vulnerability being exploited. Microsoft Threat Intelligence attributes the campaign; which operators ran it is not established.

Microsoft: anatomy of the ChainDrop worm →

N-able N-central: authentication bypass, then Take Control on managed devices

CVE-2026-18556 is an authentication bypass through an alternate path or channel, and CVE-2026-18577 is the related attack path found days later. An attacker got unauthenticated remote admin access, then used Take Control onto managed devices and installed a Cloudflared service for persistence. N-able says a limited number of customers were affected, and hosted environments were mitigated by N-able itself.

Affected

N-central through 2026.1. N-able has not published a full version range.

Fixed

Hotfix 2, version 2026.3.1.10, which supersedes Hotfix 1 from 2 August.

Do this

Apply Hotfix 2 if you have not. If you patched more than a few days after release, treat the environment as possibly compromised: audit users and password resets, and use the detection template N-able published.

Exploited

Yes. CISA added the two CVEs to KEV on 3 and 4 August.

N-able security update →N-able detection recipe →

VMware vCenter: directory traversal to RCE, then ransomware

CVE-2026-59310 is a directory traversal in the Syslog service leading to arbitrary code execution, and CVE-2026-59309 is an authentication bypass in the VMware Directory Service. Both are CVSS 9.8 and both need only network access to vCenter, which in practice means control of the virtualisation estate and every guest on it.

Affected

vCenter Server, including version 7.0, which is out of general support.

Fixed

9.1.0.0300, 9.0.2.0100, 8.0 U3k and 8.0 U2f. Version 7.0 only with an extended support contract. Broadcom lists no workarounds.

Do this

Patch, then hunt for reverse SSH tunnels, cron persistence, unexpected SSH and WebSocket activity, and ESXi files with a .babyk extension. Patching vCenter without checking the hypervisors is half a fix.

Exploited

Yes. CISA added CVE-2026-59310 to KEV on 18 August, marked as used in ransomware campaigns.

Broadcom advisory VMSA-2026-0006 →

JetBrains TeamCity: unauthenticated RCE through the agent polling protocol

Deserialisation of untrusted data in the agent polling protocol lets an attacker with HTTP access bypass authentication and run OS commands with the TeamCity server privileges. That means build configurations, stored credentials, and the integrity of every artifact the server produces. CVSS 9.8.

Affected

All TeamCity On-Premises versions. TeamCity Cloud is not affected.

Fixed

2025.11.7 and 2026.1.3. JetBrains also shipped a security patch plugin for 2017.1 and later.

Do this

Upgrade, or install the patch plugin. Then look for com.thoughtworks.xstream.converters.ConversionException in server logs, which suggests an attempt, and ForbiddenClassException, which means the patch blocked one. Check for build agents you did not add, especially names starting with scan, and rotate every credential the server held.

Exploited

Yes. JetBrains confirmed active and attempted exploitation, and CISA added it to KEV on 5 August, marked as used in ransomware campaigns.

JetBrains own Cadence service was breached through an unpatched TeamCity. That entry is in the Providers section.

JetBrains advisory →JetBrains exploitation update →

Gitea: RCE through the diffpatch API

CVE-2026-60004 lets an attacker install a Git hook through the diffpatch API and get remote code execution on the Gitea host, CVSS 9.8. The same release fixes CVE-2026-59774, unauthenticated arbitrary file read through the Org-mode #+INCLUDE directive.

Affected

Gitea before 1.27.1. Gitea Cloud instances were upgraded automatically.

Fixed

1.27.1.

Do this

Upgrade to 1.27.1 or later. If your instance was internet-facing and unpatched through August, treat the host as suspect: a forge server holds the SSH keys and tokens for everything it hosts, so rotate them.

Exploited

Yes. CISA added CVE-2026-60004 to KEV on 25 August.

Gitea 1.27.1 release →Advisory GHSA-rcr6-4jqh-j84m →

WordPress: unauthenticated RCE on a stock install, no plugins required

CVE-2026-60137 is a SQL injection through author__not_in in WP_Query. CVE-2026-63030 is a REST API batch-route confusion that reaches authenticated endpoints over /wp-json/batch/v1 without authenticating. Chained, they let an unauthenticated attacker create an administrator account and then upload a plugin or a web shell.

Affected

CVE-2026-60137 on 6.8.0 through 6.8.5, 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. CVE-2026-63030 on 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. Versions before 6.8 are not affected.

Fixed

6.8.6 for the first one, 6.9.5 and 7.0.2 for the chain.

Do this

Update. WordPress enabled forced automatic updates for the affected versions, but check anyway. If you are stuck, block anonymous access to /wp-json/batch/v1 and ?rest_route=/batch/v1 at the WAF, and audit for administrator accounts you do not recognise.

Exploited

Yes. VulnCheck canaries saw exploitation from 20 July, and CISA added it to KEV on 21 July. Wordfence says it blocked more than 11 million attempts and saw admin accounts being created, which is their figure from their own page.

WordPress 7.0.2 release →VulnCheck analysis →

SonicWall SMA1000: SSRF and code injection, both exploited

CVE-2026-15409 is an SSRF in the Appliance Work Place interface, CVSS 10.0, reachable by an unauthenticated attacker. CVE-2026-15410 is code injection in the Appliance Management Console that lets an authenticated administrator execute arbitrary OS commands. SonicWall has confirmed exploitation in the wild.

Affected

SMA 1000 series (6210, 7210, 8200v and the CMS) on 12.4.3-03245, -03387, -03434 and 12.5.0-02283, -02624, -02800, on every hypervisor.

Fixed

12.4.3-03453 and 12.5.0-02835 for these two. A later advisory lists those same builds as vulnerable to more exploited bugs, so install 12.4.3-03526 or 12.5.0-02952 instead.

Do this

Patch to the later builds, then do a forensic review. If you find signs of compromise, re-image or redeploy, change all passwords and reset TOTP. Only trust configuration backups taken before the December hotfixes.

Exploited

Yes. CISA added both to KEV on 14 July, marked as used in ransomware campaigns.

SonicWall product notice →SonicWall follow-up notice →

SimpleHelp: forged OIDC tokens made a technician account

Identity tokens submitted during OIDC login were accepted without verifying their cryptographic signature. A remote unauthenticated attacker could submit a forged token with arbitrary identity claims and get a fully authenticated technician account, and the CVE text says MFA could be bypassed too. CVSS 10.0 on the v3.1 scale.

Affected

SimpleHelp 5.5.0 up to but not including 5.5.16, and 6.0 pre-release builds before 6.0 RC2. Only servers with an OIDC auth service enabled where a technician group uses it with group authenticated logins turned on. That setting is off by default for new groups.

Fixed

5.5.16, or 6.0 RC2 and later.

Do this

Upgrade. Then review technician accounts for ones you did not create, and check which groups allow group authenticated logins. The attacker also needs to come from an allowed technician-login IP and pass the group auth filters, which is why this one is narrower than the score suggests.

Exploited

Yes. CISA added it to KEV on 29 June. The fix date is disputed: the Canadian Cyber Centre says 26 May, BleepingComputer says 9 June.

SimpleHelp vulnerability KB →

Splunk Enterprise: unauthenticated file creation through the PostgreSQL sidecar

CVE-2026-20253 is missing authentication for a critical function: an unauthenticated user can create or truncate arbitrary files through a PostgreSQL sidecar service endpoint. File creation as the Splunk user is a short step to code execution on a search head.

Affected

Splunk Enterprise 10.2 before 10.2.4 and 10.0 before 10.0.7.

Fixed

10.2.4 and 10.0.7. If you do not use the PostgreSQL sidecar, set [postgres] disabled = true in server.conf.

Do this

Upgrade, or disable the sidecar, and restart. Check the filesystem for files written by the Splunk service account that you cannot account for.

Exploited

Yes. CISA added it to KEV on 18 June.

NVD record for CVE-2026-20253 →

Check Point VPN: authentication bypass in the deprecated IKEv1 path

A logic flaw in certificate validation lets an attacker establish a VPN session with no valid password. Post-authentication work is still needed to reach internal resources, but the network perimeter is gone. CVSS 9.3. You are vulnerable only if remote access VPN or Mobile Access is enabled and IKEv1 is enabled for remote access and gateways accept legacy clients and a machine certificate is not mandatory.

Affected

Remote Access VPN, Mobile Access and Spark Firewall on R80.20.X, R80.40, R81, R81.10, R81.10.X, R81.20, R82, R82.00.X and R82.10.

Fixed

Per-checkpoint hotfixes under sk185033. Per the NHS England alert: R81.20 Jumbo Hotfix Take 142 or later, R82 Take 104 or later, R82.10 Take 20 or later. End-of-support versions must be upgraded.

Do this

Apply the hotfix, or turn off legacy client support, set remote access to IKEv2 only, or make machine certificate authentication mandatory. Audit logs back to 7 May for sessions you cannot account for.

Exploited

Yes. Check Point Research observed it, with one confirmed case of post-compromise activity by a Qilin ransomware affiliate. CISA added it to KEV on 8 June. The gap between first exploitation on 7 May and discovery on 4 June is the number to remember.

Check Point hotfix notice →NHS England cyber alert →

Drupal core: SQL injection, exploited within two days

SQL injection in Drupal database abstraction API lets an anonymous user inject SQL: read data, and in some configurations escalate to privilege escalation or remote code execution. CVSS 9.8. Only sites on PostgreSQL are exploitable, but the releases carry other dependency fixes for everyone.

Affected

8.9.0 before 10.4.10, 10.5.0 before 10.5.10, 10.6.0 before 10.6.9, 11.0.0 before 11.1.10, 11.2.0 before 11.2.12, 11.3.0 before 11.3.10.

Fixed

10.4.10, 10.5.10, 10.6.9, 11.1.10, 11.2.12 and 11.3.10. Drupal 8 and 9 are end-of-life and get best-effort patches only.

Do this

Run composer update to the fixed release for your branch, then drush updb. On MySQL or MariaDB you are not exposed to this CVE specifically, but take the release anyway.

Exploited

Yes. Drupal own advisory records exploit attempts in the wild on 22 May, and CISA added it to KEV the same day, two days after the advisory.

Drupal advisory SA-CORE-2026-004 →

TanStack npm: 84 malicious versions through a trusted publishing pipeline

84 malicious versions across 42 @tanstack/* packages, two per package, published in a six-minute window on 11 May. The payload ran a 2.3 MB obfuscated file at install time that harvested AWS and GCP credentials, Kubernetes service-account tokens, Vault tokens, .npmrc, GitHub tokens and SSH keys, then enumerated packages the victim maintained and republished them with the same injection. Exfiltration went over a messenger file-upload network, so there is no attacker domain to block.

Affected

Anything installed from npm in that window. Each affected package has its own fixed version in the advisory table. Last known-good for most packages was published on 15 March.

Fixed

Per package, in the advisory affected-products table. Affected versions were deprecated or unpublished.

Do this

Delete node_modules and the lockfile, pin every @tanstack/* dependency to a version published before 11 May 19:00 UTC, and reinstall. Then treat the machine as compromised and rotate everything the install could reach. In CI, treat the runner as compromised.

Exploited

Yes. CISA added it to KEV on 27 May, marked as used in ransomware campaigns. The publish was authenticated by the legitimate GitHub Actions OIDC trusted-publisher binding and the workflow was never modified.

This is the root of the Nx Console and GitHub internal repository incidents in the Providers section.

Advisory GHSA-g7cv-rxg3-hmpx →TanStack postmortem →

Linux kernel "Copy Fail": any local user becomes root

A flaw in the algif_aead module of the kernel AF_ALG crypto API lets any unprivileged local account become root, reliably, from a 732-byte script. It chains an AF_ALG socket with splice() into a controlled four-byte write to a page-cache page, then corrupts a setuid binary such as /usr/bin/su. No race window and no kernel-specific offsets. The researchers verified it on Ubuntu, Amazon Linux, RHEL and SUSE.

Affected

CVE-2026-31431. Every mainstream distribution shipping a kernel built between 2017 and the patch.

Fixed

Upstream commit a664bf3d603d, which reverts the 2017 in-place optimisation. Per-distribution version numbers were still rolling out when CERT-EU published, so run your distribution kernel update and check its tracker rather than trusting a number.

Do this

Update the kernel package and reboot. Before you can, echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf then rmmod algif_aead. That does not break LUKS, kTLS, IPsec, the default crypto libraries or SSH. Block AF_ALG socket creation by seccomp on containers and CI runners whatever your patch status.

Exploited

Yes. A public proof of concept shipped with the disclosure and CISA added it to KEV on 1 May. It was disclosed on 29 April, two days before the patch wave landed.

copy.fail write-up →CERT-EU advisory 2026-005 →