Security by Flavio Copes

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

Wed, 04 Nov 2026 12:00:00 GMT

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.

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

Tue, 03 Nov 2026 12:00:00 GMT

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.

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

Tue, 03 Nov 2026 12:00:00 GMT

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`.

GitBook incident post mortem

Chainstack: customer account data read over five days

Tue, 03 Nov 2026 12:00:00 GMT

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.

Chainstack incident notice

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

Mon, 02 Nov 2026 12:00:00 GMT

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.

Trigger.dev: environment variables read for some organisations

Sun, 01 Nov 2026 12:00:00 GMT

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.

Northflank: assume every environment variable was decrypted

Fri, 30 Oct 2026 12:00:00 GMT

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.

Northflank status update

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

Wed, 28 Oct 2026 12:00:00 GMT

`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.

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

Wed, 28 Oct 2026 12:00:00 GMT

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.

Magento and Adobe Commerce: PolyShell uploads, now in KEV

Tue, 27 Oct 2026 12:00:00 GMT

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.

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

Tue, 27 Oct 2026 12:00:00 GMT

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.

Warp disclosure coverage

Cloudflare: 155 AI responses contained other customers data

Mon, 26 Oct 2026 12:00:00 GMT

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.

Cloudflare: KV cache exposure and remediation

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

Wed, 21 Oct 2026 12:00:00 GMT

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.

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

Wed, 21 Oct 2026 12:00:00 GMT

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.

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

Wed, 21 Oct 2026 12:00:00 GMT

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.

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

Wed, 21 Oct 2026 12:00:00 GMT

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.

Railway preliminary report

OVHcloud CLI: release binaries replaced with a credential stealer

Mon, 19 Oct 2026 12:00:00 GMT

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`.

OVHcloud advisory GHSA-862f-55f5-vmvw

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

Mon, 19 Oct 2026 12:00:00 GMT

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.

Plex security update

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

Mon, 19 Oct 2026 12:00:00 GMT

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.

Zeabur incident report

PingCAP: stolen service-account credentials, a month inside

Mon, 19 Oct 2026 12:00:00 GMT

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.

PingCAP security update

OpenCode: stored provider keys taken in a distillation attack

Sat, 17 Oct 2026 12:00:00 GMT

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.

Coverage of the OpenCode incident

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

Fri, 16 Oct 2026 12:00:00 GMT

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.

Studio incident notice, in Japanese

BeyondTrust Remote Support: authentication bypass on self-hosted appliances

Thu, 15 Oct 2026 12:00:00 GMT

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.

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

Tue, 13 Oct 2026 12:00:00 GMT

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.

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

Mon, 12 Oct 2026 12:00:00 GMT

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.

Fireworks AI: secrets injected into evaluation jobs were readable

Fri, 09 Oct 2026 12:00:00 GMT

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.

Fireworks AI security bulletin

Two npm packages republished with credential-stealing worms

Thu, 08 Oct 2026 12:00:00 GMT

`@subql/common@5.8.3` and `tensorlake@0.5.144` 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.

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

Mon, 05 Oct 2026 12:00:00 GMT

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.

Citrix NetScaler: unauthenticated command injection in the default configuration

Sun, 27 Sep 2026 12:00:00 GMT

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.

Gyazo: 23.6 million user records and 490 million image records

Wed, 16 Sep 2026 12:00:00 GMT

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.

GitLab: unauthenticated arbitrary file read, CVSS 10.0

Thu, 10 Sep 2026 12:00:00 GMT

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.

GitLab patch release 19.3.2

Brevo: a SAML flaw let one account reach other organisations

Thu, 10 Sep 2026 12:00:00 GMT

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.

Brevo incident write-up

Starlette: a malformed Host header defeats path-based auth

Wed, 02 Sep 2026 12:00:00 GMT

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`.

Coder registry served tampered Terraform modules for 14 hours

Tue, 01 Sep 2026 12:00:00 GMT

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.

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

Fri, 28 Aug 2026 12:00:00 GMT

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.

JetBrains Cadence was breached through an unpatched TeamCity

Fri, 28 Aug 2026 12:00:00 GMT

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.

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

Thu, 20 Aug 2026 12:00:00 GMT

`arrayref@0.3.10` was published with a dependency on `proc-macro1`, a typosquat of `proc-macro2` whose build script downloaded a malicious payload. `internment@0.8.7` and `append-only-vec@0.1.9` were republished the same way. The malicious `arrayref` version was live for 86 minutes.

Affected: `arrayref@0.3.10`, `internment@0.8.7`, `append-only-vec@0.1.9`, 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.

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

Tue, 11 Aug 2026 12:00:00 GMT

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.

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

Thu, 06 Aug 2026 12:00:00 GMT

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.

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

Tue, 04 Aug 2026 12:00:00 GMT

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.

Microsoft: anatomy of the ChainDrop worm

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

Mon, 03 Aug 2026 12:00:00 GMT

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.

VMware vCenter: directory traversal to RCE, then ransomware

Wed, 29 Jul 2026 12:00:00 GMT

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.

Broadcom advisory VMSA-2026-0006

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

Tue, 28 Jul 2026 12:00:00 GMT

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.

Gitea: RCE through the diffpatch API

Mon, 27 Jul 2026 12:00:00 GMT

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.

JetBrains TeamCity: unauthenticated RCE through the agent polling protocol

Mon, 27 Jul 2026 12:00:00 GMT

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.

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

Fri, 17 Jul 2026 12:00:00 GMT

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.

webhot.dk was rebuilt from scratch after ransomware

Wed, 15 Jul 2026 12:00:00 GMT

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.

Computerworld Denmark report

SonicWall SMA1000: SSRF and code injection, both exploited

Tue, 14 Jul 2026 12:00:00 GMT

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.

Grok Build was uploading whole Git repositories, history included

Tue, 14 Jul 2026 12:00:00 GMT

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.

SimpleHelp: forged OIDC tokens made a technician account

Mon, 29 Jun 2026 12:00:00 GMT

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.

SimpleHelp vulnerability KB

Splunk Enterprise: unauthenticated file creation through the PostgreSQL sidecar

Thu, 18 Jun 2026 12:00:00 GMT

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.

NVD record for CVE-2026-20253

Klue: one stale credential and a cascade through customers Salesforce

Thu, 18 Jun 2026 12:00:00 GMT

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.

ServiceNow: an unauthenticated API endpoint used to query customer instances

Tue, 09 Jun 2026 12:00:00 GMT

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.

Coverage of the ServiceNow incident

Check Point VPN: authentication bypass in the deprecated IKEv1 path

Mon, 08 Jun 2026 12:00:00 GMT

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.

Drupal core: SQL injection, exploited within two days

Fri, 22 May 2026 12:00:00 GMT

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.

Drupal advisory SA-CORE-2026-004

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

Wed, 20 May 2026 12:00:00 GMT

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.

TanStack npm: 84 malicious versions through a trusted publishing pipeline

Mon, 11 May 2026 12:00:00 GMT

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.

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

Tue, 05 May 2026 12:00:00 GMT

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.

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

Fri, 01 May 2026 12:00:00 GMT

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.