Tencent Zhuque Lab published a full write-up and working demos on 12 October 2026 for CVE-2026-74580, which it calls Vghost. The bug is in the Linux kernel's vhost subsystem, which accelerates network and other I/O for virtual machines and containers through device nodes such as /dev/vhost-net and /dev/vhost-vsock. vhost caches the memory mapping behind each virtual ring and treats a cache hit as proof the region was already checked, but the cache was not cleared when the VHOST_SET_VRING_ADDR or VHOST_SET_VRING_NUM commands changed a live ring's addresses or size. With a device IOTLB attached, the old mapping keeps being used and the kernel copies data outside the mapped region. On a host this gives a local user deterministic arbitrary kernel read and write, a KASLR bypass and root, with no heap grooming or race. Where a guest's virtio device sits behind a virtual IOMMU with iommu_platform on, an untrusted guest can trigger the same bug to make the host kernel write out of bounds into the host's QEMU process, which can be used to hijack or crash it. Tencent reproduced local-user-to-root on Ubuntu 26.04, RHEL 9.8, Amazon Linux 2023, Azure Linux 3.0 and Oracle Linux 10.2; on Ubuntu the node is limited to the kvm group, but on the other four it was world-accessible (mode 0666). The flaw dates from a 2017 change (Linux 4.11) combined with a 2020 change (5.9). The kernel.org CNA scores it 8.8 with scope changed; Red Hat scores 7.3 (scope unchanged), Amazon 7.8 and Oracle 7.3. Tencent says its Corvus AI multi-agent system found the bug; the fix (commit de845981da67) was released on 3 August and credits it with an Assisted-by line. No exploitation is reported. (sources: Tencent Zhuque Lab write-up; the upstream kernel commit)
Tencent Zhuque Lab — Vghost: Beyond the Privilege Boundary (CVE-2026-74580, 12 Oct 2026)
Wordfence said on 12 October 2026 that its Argus AI system found CVE-2026-39919, a critical heap buffer overflow in the Ghostscript PostScript and PDF interpreter, during a WordPress 7.1 assessment on 23 August. A PDF containing a JPEG 2000 image with low-bit-depth samples and mismatched component resolutions makes Ghostscript write 1,024 bytes into a 256-byte buffer. Wordfence rates it 9.8 and turned it into unauthenticated remote code execution on a purpose-built WordPress test server, where WordPress calls ImageMagick through PHP Imagick to make a PDF thumbnail and ImageMagick launches Ghostscript. Ghostscript 9.21 to 10.07.1 contain the vulnerable code. In its 15 September tests, the Ghostscript packages in Debian 12 and 13, Ubuntu 22.04, 24.04 and 26.04, Fedora 44, AlmaLinux 10, Alpine and the official WordPress Docker image were all still affected. Its two exploits did not work against those stock packages in 10,240 attempts, but did work after changes to fonts, language settings and one system library, so exploitation depends on the environment. Stock WordPress does not allow anonymous Media Library uploads; an attacker needs some way to upload a PDF that the site then renders. Artifex fixed the flaw in Ghostscript 10.08.0 on 8 September and backported fixes to older lines. Wordfence has seen no exploitation in the wild. Any application that renders untrusted PDFs through Ghostscript is in scope, not only WordPress.
Wordfence — Argus discovers critical vulnerability in Ghostscript, the program that turns uploaded PDFs into thumbnails (12 Oct 2026)
Docker said on 12 October 2026 that from 26 August 2024, converting a Docker Hub personal account into an organization also re-assigned that account's personal access tokens (PATs) to the account named as the new owner, without rotating the secret and without asking or telling that owner. An attacker could create an account and a PAT, convert it, name a target user as owner, and keep using the token with the target's registry scope, so they could pull, push or delete images in the target's repositories and in organizations the target could reach. Docker rated it critical because it allowed publishing images under a legitimate name. It did not give web access or let anyone change passwords, email or two-factor settings. Researchers Peter Molnar and Krisztian Hozak reported it on 30 September 2026 and Docker deployed a fix in under four hours. Docker says it reviewed every conversion back to August 2024, found no evidence of exploitation after examining 304,000 pushes made with transferred tokens, emailed affected users and organization owners on 2 October, and deactivated transferred PATs on 8 October unless owners asked to keep them. Conversion no longer transfers PATs and now needs the named owner's consent. Updated 13 Oct 2026 (BleepingComputer): BleepingComputer's report is dated 13 October 2026; details credited to BleepingComputer on this card come from that report.
Docker — Docker Hub security advisory: personal access tokens transferred during account-to-organization conversions (12 Oct 2026)
SSD Secure Disclosure published an advisory on 12 October 2026 covering a three-bug chain on LG webOS smart TVs that lets an attacker on the same local network gain root without a PIN or any owner interaction. Entry is through the ThinQ pairing service on port 3001: the attacker replays a sync-demo app manifest signed with a test certificate the firmware still trusts, and a permission in that manifest makes the pairing service skip the PIN and hand over a privileged key. With the key, the attacker launches the built-in cmp-client app to an attacker-controlled page; the page keeps PalmServiceBridge access and abuses the root-running pmlogd logging service with unchecked shell input. The chain was demonstrated on the 32LQ636BPSA and 27TQ600SW models running webOS 7.5.7-25 (firmware 04.54.40); whether other models or builds are affected is not stated. An anonymous researcher took third place in the LG webOS category at TyphoonPWN 2026 (Seoul, May) with the demo. No CVE identifiers have been assigned, and no exploitation in the wild was reported in the sources used here. LG has issued a firmware fix per SSD. Owners should check for a TV firmware update; no workaround is available if the update cannot be applied. This is separate from Bitdefender's 2024 webOS findings and from an earlier TyphoonPWN path-traversal chain on a different port. Correction (02 Nov 2026): removed The Hacker News as a source. (source: SSD Disclosure)
SSD Secure Disclosure — LG webOS sync-demo preauth RCE / local root chain (12 Oct 2026)
Progress Software, the CNA for MarkLogic, published 20 CVE records (CVE-2026-85957 to CVE-2026-85976) on 12 October 2026, all pointing to its MarkLogic Critical Security Alert Bulletin for October 2026. Every flaw is in MarkLogic Server, the enterprise multi-model database used for document and metadata-heavy workloads, and affects the 12.x releases before 12.1.0 and, for most of them, 11.x before 11.3.7. The items to read first are the unauthenticated network ones. In deployments using SAML, a remote attacker could get the server to accept an assertion it should reject (CVE-2026-85962, 7.5). A separate validation weakness lets the server accept a token it should refuse (CVE-2026-85958, 7.5). On 11.x, the SAML parser processes external DTDs and entities (XXE, CVE-2026-85957, 7.5). The deprecated OpsDirector component carries SSRF and a hard-coded key that an unauthenticated attacker could use to forge trusted requests (CVE-2026-85963, 7.5). Azure deployments may record security-sensitive data in logs (CVE-2026-85961, 7.5), and S3 connections may use cleartext transport (CVE-2026-85975, 7.5). Progress's top score is 8.0, for memory-safety defects in the JavaScript engine integration that a high-privileged attacker could use to corrupt memory (CVE-2026-85965). The rest include predictable Query Console CSRF tokens that could lead to server-side code running with a victim's permissions (CVE-2026-85960, 7.5), Query Console path traversal and information exposure (7.7), out-of-bounds read and write and a second XXE (7.1), Kerberos, TLS hostname and cluster-join transport weaknesses (7.4), world-readable log files (7.1), XSS (6.1) and response splitting (5.4). The CVE records do not mention exploitation or public exploit code. (sources: the Progress MarkLogic bulletin; the Progress-assigned CVE records)
Progress Community — MarkLogic Critical Security Alert Bulletin, October 2026
Independent researcher Simon Koeck published on 12 October 2026 a write-up of a critical chain in Google's shared DevSite platform (the Flask/OAuth front end used by Google developer documentation sites). A /oauth2authorize response set a large Flask session cookie that was signed but not encrypted. Decoding it exposed a pickle-serialized OAuth2WebServerFlow object holding a Google OAuth client_id and client_secret in cleartext; that same client_secret was the Flask SECRET_KEY (itsdangerous cookie-session derivation), so anyone with a cookie could recover the key, forge a valid session, and smuggle a malicious pickle into the OAuth callback's pickle.loads path for remote code execution. Koeck showed the developers.google.com signing key also validated sessions on other DevSite hosts including firebase.google.com, developer.android.com, source.android.com and docs.partner.android.com. Timeline: reported 6 Aug 2026, triaged/accepted 7 Aug, $90,000 VRP reward decided 27 Aug (T2 S0 RCE base $75,000 × 1.2), fixed 7 Oct 2026. Google's fix path, per the write-up: rotate the exposed OAuth secrets and kill sessions signed with them; give each deployment its own high-entropy Flask SECRET_KEY unrelated to OAuth; keep the OAuth flow object server-side with only an opaque reference in the cookie; and stop unpickling client-supplied data. No evidence of exploitation in the wild was published. (sources: Simon Koeck write-up; Cybersecurity News)
Simon Koeck — How I Found a $90,000 Remote Code Execution Vulnerability in Google (12 Oct 2026)
GitLab published a critical patch release on 12 October 2026 (versions 19.4.2, 19.3.4 and 19.2.8 for Community Edition and Enterprise Edition) remediating CVE-2026-97229, an integer overflow in the CI/CD Regular Expression Compiler that, under certain conditions, could let an unauthenticated attacker execute arbitrary code on the GitLab server through a specially crafted regular expression in a CI/CD configuration. GitLab rates it CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Impacted self-managed installs are all CE/EE versions from 19.2 before 19.2.8, from 19.3 before 19.3.5, and from 19.4 before 19.4.2. GitLab.com is already patched; GitLab Dedicated customers do not need to act. The advisory does not state that the flaw has been exploited in the wild. Researcher joaxcar reported it via HackerOne. GitLab's advisory now titles the release 19.4.2, 19.3.5 and 19.2.8 and lists the affected 19.3 range as before 19.3.5; it says 19.3.4 had a bug that affected merge request pages when the Ona integration was enabled, fixed in 19.3.5. The same release also ships other High/Medium fixes (XSS in syntax highlighting, several authorization issues, Duo Agent Platform input neutralization, and more) — this card is the Critical regex RCE only. UPDATE (22 Oct): GitLab fixed a separate, further regular-expression-compiler flaw, CVE-2026-110264 (CVSS 10.0, all versions from 7.0 affected), on 21 October in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13; see the CVE-2026-110264 card. UPDATE (29 Oct 2026, Perth; Alpine Linux; GitLab): Alpine Linux said on 28 October that on 20 and 21 October an attacker tried to exploit CVE-2026-97229 on its GitLab instance, which was still running 19.3.4 without the 12 October fix; crafted CI configurations from a newly registered account crashed GitLab worker processes 8 times, and in 4 of those crashes the attacker got partway through the exploit and failed at the next step. Alpine says it found no evidence the attack succeeded but cannot rule it out, so it treated the instance as compromised, rebuilt it, reset all passwords and replaced GitLab's secret keys, and that its aports repository, packages and 21 October releases were not tampered with and no signing keys were on the GitLab server. Alpine also says its upgrade to GitLab 19.3.6 on 22 October did not fix the flaw, because the fix is a set of patches to the Ruby that GitLab bundles only in its official packages and container images; the underlying bug is in Ruby's Onigmo regular-expression engine, fixed upstream on 23 October in Ruby 3.3.13, 3.4.12 and 4.0.9, so installations that run GitLab with their own Ruby (from source or a custom container image) also need one of those Ruby releases or later. As of 29 October, GitLab's advisory lists six threat detections released to help self-managed customers detect exploitation attempts. (source: Alpine Linux; GitLab) UPDATE (30 Oct 2026, Perth; CISA): CISA added CVE-2026-97229 ("GitLab Community Edition and Enterprise Edition Integer Overflow or Wraparound vulnerability") to its Known Exploited Vulnerabilities catalog on 29 October 2026 based on evidence of active exploitation, with a remediation due date of 1 November 2026 for US federal civilian agencies. (source: CISA) UPDATE (2 Nov 2026, Perth; BleepingComputer): according to BleepingComputer (2 Nov), Shadowserver said it is tracking over 1,000 GitLab instances vulnerable to CVE-2026-97229 and over 11,300 vulnerable to CVE-2026-110264, out of around 39,000 GitLab instances it sees daily. (source: BleepingComputer)
Emacs maintainer Sean Whitton disclosed on the oss-security list on 11 October 2026 that the fix for CVE-2026-79992 was incomplete. CVE-2026-79992 is the TRAMP local command execution flaw that Bas Alberts of GitHub Security Lab reported in August. Wonyoung Jung of 78ResearchLab, using its PatchHawk tool, found that tramp-user-regexp still let through characters such as !, #, &, comma and control characters in the user part of a remote file name, so a crafted name can still inject commands into the local shell TRAMP opens while it sets up a connection. The original August report showed that merely checking such a file name, for example through a symlink target committed to a git repository or a recursive directory scan, ran the payload before any SSH connection was made. MITRE assigned CVE-2026-108976 on 11 October (CVSS 3.1 7.8, local attack vector) for Emacs before 31.2 and TRAMP through 2.8.2. A patch by TRAMP maintainer Michael Albinus is attached to the post; it will ship in Emacs 31.2, which the maintainers say will not be released soon. No exploitation has been reported.
oss-security — Sean Whitton (Emacs maintainer): Incomplete fix for Emacs CVE-2026-79992 (11 Oct 2026)
MLflow published security advisory GHSA-26p8-2jq9-3vq9 on 9 October 2026, rated Critical (CVSS 3.1 9.8), for a remote code execution flaw in the open-source MLflow tracking server. Support for third-party scorers, added in MLflow 3.12.0, lets the server import a Python module named in a request as long as the module path starts with one of four allowed scorer package names (ragas, deepeval, trulens, phoenix), then build a class from it. An HTTP caller can chain this with MLflow's normal experiment, run and artifact-upload endpoints: create an experiment whose local artifact location points inside an allowed scorer package, create a run, upload a Python file as a run artifact, and then ask the scorer-invoke endpoint (/ajax-api/3.0/mlflow/scorer/invoke) to load it. The code runs in the MLflow server process before any trace checks. On a default server with no authentication, such as the official MLflow container image the reporter tested (v3.14.0, which ran as root), this gives any network caller arbitrary code execution and access to the data, credentials and models the server can reach. With MLflow basic authentication turned on, a login is still needed, but the scorer endpoint does no per-experiment permission check. The advisory lists affected versions as 3.12.0 up to but not including 3.17.0 and the fix as 3.17.0 (released 7 October); no CVE ID has been assigned. MLflow has not reported exploitation. MLflow is widely used for machine-learning experiment tracking and model registries, often exposed inside data-science networks without authentication. (source: MLflow GitHub security advisory)
MLflow — GHSA-26p8-2jq9-3vq9: Remote code execution on unauthenticated MLflow servers via third-party scorer deserialization (9 Oct 2026)
Anthropic published a GitHub security advisory (GHSA-pq7j-f95f-qfcv) on 9 October 2026, and the CVE record CVE-2026-86063 followed on 13 October. The plugin installation flow in Claude Code and Claude Desktop ran git checkout on the 40-character commit SHA that a marketplace had pinned, but never checked that the resulting HEAD actually matched that SHA. Someone controlling a plugin's upstream repository on a Git host that allows branch names shaped like SHAs could create a branch named after the reviewed commit; checkout would then pick the branch tip, so the attacker's code was installed while the pin appeared to be honoured. Exploitation needs a user to install the malicious plugin pinned to the supposedly safe hash. Anthropic rates it CVSS 4.0 7.5 (high) and fixed it in Claude Code 2.1.179. It says users on standard auto-update already have the fix and those who update by hand should move to the latest version. Or Nevo Michrowski of Air Security reported the issue. No exploitation is reported. (source: Anthropic's GitHub security advisory)
Anthropic (GitHub advisory GHSA-pq7j-f95f-qfcv) — Plugin commit SHA pin bypass allows installation of attacker-controlled code (9 Oct 2026)
The XRP Ledger developers published a vulnerability disclosure report on 9 October 2026 for two bugs fixed in xrpld 3.4.1, the reference server for the XRP Ledger, which shipped as an emergency binary-only release on 25 September with source code published only at disclosure. The serious one is an integer overflow in the payment engine affecting xrpld 3.4.0 and earlier. When a single payment consumed many offers from the ledger's built-in order book, the engine summed what the buyer owed with plain 64-bit addition and no overflow check, so a large enough total wrapped around to a small number: each offer owner was paid in full while the buyer was charged only the wrapped total, creating new XRP. The invariant meant to confirm no transaction creates XRP used the same arithmetic and missed it. An attacker controlling all the accounts involved needed only a few hundred XRP in reserves plus fees, with hundreds of deliberately mispriced offers. Cayden Liao and Veria AI reported it through the XRPL bug bounty on 22 September; RippleX reproduced it, raised it from Major to critical, and says more than 80 per cent of default trusted-list validators ran 3.4.1 the day it shipped and that it found no evidence of exploitation on any public network. The second bug, a Batch inner-transaction wrapper validation gap (fixBatchV1_2) in 3.3.0 and 3.4.0, could have stalled ledger validation on a mixed-version network, but the Batch amendment was never active on Mainnet. No CVSS score was published. (source: XRPL vulnerability disclosure report)
XRPL.org — Vulnerability Disclosure Report for xrpld 3.4.1 (published 9 Oct 2026)
Patchstack said on 8 October 2026 that attackers are exploiting CVE-2026-85097, a critical flaw in Bricksforge, a commercial add-on for the Bricks visual site builder on WordPress that adds Pro Forms, animations and dynamic data features. Bricksforge is sold outside WordPress.org, so sites will not see it in the usual plugin directory alerts. The plugin checks a file's MIME type when it is first uploaded, but on form submission it trusts the file metadata the browser sends and does not validate the 'url' field in the temporaryFileUploads parameter. Wordfence, which assigned the CVE, describes the chain: an attacker with no account gets a valid nonce from the bricksforge_regenerate_nonce AJAX action, uploads a GIF/PHP polyglot that passes the image check, then submits a form whose server-side path points at the validated GIF while the url ends in .php, so the file is written as PHP and can be run. That gives full control of the site: web shells, content changes, data theft and persistence. Patchstack first saw attacks at 21:47 UTC on 7 October (8 October, 5:47am Perth). All but one request went to POST /wp-json/bricksforge/v1/form_submit; the other used /wp-admin/admin-ajax.php with the bricksforge_form_submit action. Most payloads targeted /wp-content/uploads/bricksforge/tmp/, some dropped login_admin_*.php files into normal uploads folders such as /wp-content/uploads/2026/10/, and attackers tried alternate extensions (.php5, .php7, .phtml), mixed case and URL-encoded extensions to get past filters. Patchstack logged 63 source IPs across datacentre, cloud, VPN and residential ranges, including one cluster of 44 IPs sending identical payloads within seconds, which points to automated mass exploitation; no actor has been named and no count of compromised sites published. Version note: Patchstack and Wordfence list versions up to and including 3.1.8.9 as affected and 3.1.8.10 as fixed. The vendor's public changelog has no 3.1.8.10 entry; it lists 4.0.0 (17 September) and then 4.0.1 (8 October), 'Security fix for the Pro Forms file upload', which it says affects every site with Pro Forms active, even forms with no upload field. Whether 4.0.0 is affected is not stated, so move to 4.0.1 or later. Scores differ: Patchstack rates it CVSS 10.0; the CVE record and Wordfence give 9.8. (source: Patchstack)
Patchstack — Critical unauthenticated arbitrary file upload vulnerability exploited in Bricksforge plugin (8 Oct 2026)
