The Exploit Bulletin — Saturday, October 31, 2026: 6 issues require action
Saturday, October 31, 2026 — 6 issues require action. If you run none of the software below, you are done.
Affects: GitLab CE/EE · Siemens SIMATIC IoT2050 Advanced · FreeScout · Binance · DebugBear · WordPress
1. Unauthenticated path traversal in GitLab repository commits API reads arbitrary server files (CVE-2026-85706)
CISA KEV (due 2026-09-14) · DATA EXPOSURE · CRITICAL · CVSS 10.0
VulnCheck's canary sensors recorded exploitation attempts again today (2026-10-31) and CISA has listed it as actively exploited since 2026-09-11, so any self-hosted GitLab still on an unpatched 18.7–19.3 build is exposed to unauthenticated file reads from anyone on the internet.
Improper path confinement and missing authentication enforcement in the repository commits API of GitLab CE/EE let an unauthenticated remote attacker read arbitrary files from the GitLab server. The CVSS 10.0 vector (scope changed, high confidentiality and integrity impact) means a single crafted request can expose server-side files from an instance reachable over the network, and more than a dozen public exploits exist.
Affected: GitLab CE/EE 18.7 up to but not including 18.11.12; GitLab CE/EE 19.0 up to but not including 19.0.9; GitLab CE/EE 19.1 up to but not including 19.1.8; GitLab CE/EE 19.2 up to but not including 19.2.6; GitLab CE/EE 19.3 up to but not including 19.3.2
How to Test: Confirm the running GitLab CE/EE version and compare it against the affected ranges (18.7–18.11.11, 19.0.0–19.0.8, 19.1.0–19.1.7, 19.2.0–19.2.5, 19.3.0–19.3.1). Review web and API access logs for unauthenticated requests to the repository commits API endpoints that contain path traversal sequences (e.g. ../ or encoded equivalents) or reference files outside repository paths; treat any such hits on an unpatched instance as a possible file-read compromise and rotate secrets stored on the server.
How to Patch: Upgrade GitLab CE/EE to 18.11.12, 19.0.9, 19.1.8, 19.2.6, or 19.3.2 (or later) for your release line. Until the upgrade is applied, restrict network access to the GitLab instance so that it is not reachable by unauthenticated internet clients.
Evidence: CISA KEV · VulnCheck KEV · CISA SSVC: active · BleepingComputer (2026-10-30): notes CISA's exploited listing of this flaw · FortiGuard outbreak alert on GitLab path traversal · VulnCheck XDB public exploit
2. Unauthenticated Node-RED HTTP interface allows root code execution on Siemens SIMATIC IoT2050 Advanced (CVE-2026-58115)
REMOTE CODE EXECUTION · CRITICAL · CVSS 10.0
VulnCheck's canary sensors recorded exploitation attempts against this flaw on 2026-10-30 and 2026-10-31; an unpatched IoT2050 with a reachable Node-RED interface can be fully taken over without credentials, giving attackers a foothold inside the OT network.
SIMATIC IoT2050 Advanced devices running Industrial OS with Node-RED installed do not require authentication on the Node-RED HTTP interface. An unauthenticated remote attacker can create malicious flows using nodes that execute system commands and run arbitrary code on the device with maximum privileges.
Affected: Siemens SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2), all versions < V4.3.4.1 running Industrial OS with Node-RED installed
How to Test: Check the firmware/Industrial OS version on each SIMATIC IoT2050 Advanced (6ES7647-0BA00-1YA2): anything below V4.3.4.1 with Node-RED installed is affected. Confirm whether the Node-RED HTTP interface can be opened without a login from other network segments or the internet. To check for compromise, review the deployed Node-RED flows for flows or command-executing nodes you did not create, and review the device for unexpected processes, users or outbound connections.
How to Patch: Update SIMATIC IoT2050 Advanced to V4.3.4.1 or later (Siemens download: https://support.industry.siemens.com/cs/ww/en/view/109741799/). If you cannot update yet, Siemens' mitigations are to uninstall Node-RED or harden the Node-RED installation by enabling authentication per the Node-RED User Guide. Also restrict network access to the device's Node-RED interface.
Evidence: VulnCheck KEV
3. Invite-hash trailing-space match in FreeScout user setup allows unauthenticated account takeover (CVE-2026-53595)
AUTHENTICATION BYPASS · CRITICAL · CVSS 9.4
VulnCheck's canary sensors saw exploitation attempts on 2026-10-30 and a weapon-grade exploit is in VulnCheck XDB, so an unpatched internet-facing FreeScout instance can lose its user accounts, and the mailbox contents behind them, to a single request.
FreeScout's public user-setup endpoint picks the target account only by its invite hash, then overwrites that account's email and password and logs the requester in. Activated accounts have an empty invite hash, and MySQL/MariaDB ignore trailing spaces when comparing strings, so a single URL-encoded space matches them. Any unauthenticated attacker can take over an activated account.
Affected: FreeScout versions before 1.8.224
How to Test: Check the FreeScout version shown in the admin panel or in your deployment; anything before 1.8.224 is affected, especially on MySQL or MariaDB. Search web server access logs for POST requests to /user-setup/ whose hash segment is %20 or blank. Check for unexpected changes to user email addresses or passwords, and for logins to accounts that should not have gone through invite setup again.
How to Patch: Upgrade FreeScout to 1.8.224 or later. If you can't upgrade right away, block POST requests to /user-setup/ at the reverse proxy or WAF. After upgrading, reset the passwords of any accounts whose email or password changed unexpectedly.
Evidence: VulnCheck KEV · VulnCheck XDB exploit
4. Binance loses ~$6.3B after DevOps laptop compromise and an EIP-7702 hot-wallet sweeper
CONFIRMED BREACH · CRITICAL
This is the largest crypto theft on record and the attack path is now public, so any organization running hot wallets or withdrawal services should check this week for the same laptop-to-signing-container route and EIP-7702 delegation abuse before TraderTraitor uses it again.
On October 29, attackers moved about $6.3 billion out of Binance hot wallets on ten blockchains, most of it within roughly 20 minutes. Binance says the intrusion probably started with a compromised DevOps engineer's laptop, which led to a service container that could submit withdrawal transactions. On Ethereum, the attacker used an EIP-7702 delegation with pre-signed authorizations to turn a hot wallet into a sweeper it controlled. TRM Labs attributes the theft to North Korea's TraderTraitor with high confidence. Tether, Circle and Arbitrum have frozen nearly $3 billion.
Affected: Binance hot wallets (ten blockchains, incl. Ethereum)
How to Test: List every service container or job that can submit or sign withdrawals, and check whether it can be reached from developer or DevOps endpoints. On-chain, check your hot and treasury EOAs for code beginning with 0xef0100 (an EIP-7702 delegation) or any delegation you did not authorize, and review stored pre-signed authorizations. Screen inbound deposits and counterparties against the attacker addresses published by TRM Labs and Chainalysis.
How to Mitigate: Separate signing and withdrawal infrastructure from developer laptops, using dedicated hardened hosts and multi-party approval. Alert in real time on any EIP-7702 delegation set on treasury or hot wallets, and keep a tested procedure to revoke it. Cap outflow speed per wallet, and block the published attacker addresses.
Evidence: The Hacker News: Binance confirms security incident affecting $6.3B · BleepingComputer: theft linked to compromised DevOps laptop · SecurityWeek: hallmarks of TraderTraitor · TRM Labs: EIP-7702 sweeper, attribution to North Korea · BleepingComputer: Binance probes breach
5. DebugBear monitoring script compromised, served crypto-draining JavaScript (Polymarket hit)
SUPPLY-CHAIN COMPROMISE · HIGH
DebugBear's own incident is still ongoing, so any site still loading its script may be serving attacker-controlled code to visitors right now.
Researchers traced malicious JavaScript to DebugBear, a UK website performance monitoring service. The script drained crypto from Polymarket.com users, and about $2–2.5M has been traced to an attacker wallet. Polymarket confirmed that a third-party provider was compromised and halted trading. DebugBear confirmed it is dealing with an ongoing security incident. Any site that embeds DebugBear's script may have served the same payload to its visitors.
Affected: DebugBear monitoring/RUM JavaScript snippet (served around 2026-10-29)
How to Test: Search your web properties, tag managers and CSP allowlists for DebugBear script includes. Review CSP violation reports, CDN logs and saved copies of your pages from October 29 onward for unexpected DebugBear-served code, especially wallet-connect or transaction-signing hooks. Check for user reports of unauthorized transactions or credential prompts.
How to Mitigate: Remove or disable the DebugBear snippet until DebugBear confirms the incident is contained and the script is clean. Then pin third-party scripts with Subresource Integrity, or host them yourself, and enforce a strict Content-Security-Policy.
Evidence: SecurityWeek: theft linked to DebugBear; DebugBear confirms incident · BleepingComputer: Polymarket confirms third-party provider compromise
6. Race condition in WordPress core upgrade staging paths allows unauthenticated code execution (CVE-2026-119977)
PUBLIC EXPLOIT · NO ATTACKS CONFIRMED · REMOTE CODE EXECUTION · HIGH · CVSS 8.1
WordPress 7.1.4 shipped on 2026-10-28, Wordfence reports attackers are already trying to exploit this race, and VulnCheck added it to its KEV catalog on 2026-10-30, so a site still on an older build could be taken over the next time it runs a core upgrade.
During a full-package core upgrade, WordPress stages files at predictable paths that can be reached over the web. An unauthenticated attacker who hits those paths during the upgrade window can run code on the server. WordPress 7.1.4 fixes it.
Affected: WordPress 4.7 through 7.1.3; WordPress branch releases up to and including 4.7.38, 4.8.33, 4.9.34, 5.0.30, 5.1.27, 5.2.29, 5.3.26, 5.4.24, 5.5.23 and 5.6.22
How to Test: Check the installed core version under Dashboard > Updates (or in wp-includes/version.php). Any version from 4.7 through 7.1.3 is affected. To look for compromise, review web server access logs around the times of recent core upgrades for unauthenticated requests to upgrade or staging files under wp-content and wp-admin. Also check for unexpected PHP files, new admin users or changed core files left behind after an upgrade.
How to Patch: Update WordPress core to 7.1.4. If you are pinned to an older branch, install that branch's newest security release (any release newer than the affected versions listed). Do the update during a low-traffic period and check that the site is on the fixed build once it finishes.
Evidence: VulnCheck KEV · wordfence.com: exploitation reported (cited by VulnCheck)
Read on the web · Every past edition
The Exploit Bulletin is free and daily. It publishes only what security teams must act on today — nothing else. Forward it freely.
Spot an error, or an exploit we missed? Reply here or email [email protected].
