SonicWall has warned customers to patch a SonicOS SSLVPN vulnerability that could let attackers bypass SAML authentication and its multi-factor authentication checks.
Tracked as CVE-2026-19868, the flaw carries a CVSS score of 7.1. The company has investigated a report indicating potential exploitation and strongly urges customers to upgrade promptly.
The issue affects SSLVPN only when SAML is enabled for logins. An attacker must have valid credentials for an alternate authentication method, making this different from a login bypass that requires no account. Under affected conditions, those credentials may allow access without passing the SAML controls intended to protect the connection.
SAML lets organizations use a central identity provider to handle user sign-ins. Here, the weakness concerns authentication enforcement through another login method, rather than a stated flaw in SAML itself.
Successful exploitation may also skip MFA enforced through SAML, leaving a gap between the security policy administrators expect and the checks actually applied.
Ryan Harris of The Electronic Office reported the vulnerability. SonicWall includes it among seven issues in its latest advisory. Although the exploitation warning raises urgency, the supplied details do not identify attackers, victims, attack dates, or the scale of activity. Describing a confirmed widespread campaign would therefore go beyond the available evidence.
Its session-hijacking behavior should not be treated as evidence of how CVE-2026-19868 works or what attackers have done with this newly disclosed issue.
SonicOS SSLVPN Vulnerability Exploited
The SonicWall security advisory, published November 6, also lists CVE-2026-107155 and CVE-2026-107154. Both score 8.8 and affect the management interface. They involve a permissive cross-domain policy and session validation, respectively, and could permit unauthorized operations under specific conditions. Their vectors include required user interaction.
CVE-2026-82308 is a pre-authentication heap buffer overflow in SSLVPN, rated 7.5. CVE-2026-77708 and CVE-2026-77709 affect the TACACS+ authentication client, and each scores 5.9. These flaws could cause application-level denial of service. CVE-2026-19703, rated 5.2, could expose a limited platform credential on virtual appliances to an attacker with existing local access.
Affected releases include Gen7 hardware and NSv appliances running SonicOS 7.3.3-7015 or earlier, and Gen8 hardware and NSv appliances running 8.2.2-8015 or earlier. SonicWall lists fixes in 7.3.4-7013 and later for Gen7, and 8.2.3-8015 and later for Gen8. No workaround is listed.
Administrators should prioritize patching, confirm their appliance generation, and install the matching fixed release. Previous SonicOS vulnerability reporting covers different flaws and firmware fixes, so older patch guidance should not replace this advisory’s requirements. Review enabled authentication methods and check VPN login activity while completing the upgrade.
Hackers have launched more than 240,000 exploit attempts against a WordPress Core vulnerability that can allow attackers to run malicious code without logging in. According to the supplied Wordfence report, attacks began on October 28, 2026, the same day WordPress released a security update addressing the flaw.
Tracked as CVE-2026-119977, the vulnerability carries a high severity CVSS score of 8.1. It affects unpatched WordPress branches from 4.7 through 7.1.3. Researcher Umut Bayram reported the weakness, which involves predictable, publicly accessible folders created during full WordPress Core upgrades.
WordPress addressed the issue in its October 28 security release, alongside several other security fixes. Older branches also received backported patches. Cybersecuritynews.com’s earlier coverage of WordPress 7.1.4 security fixes explained how the update changes temporary folder handling to reduce exposure during upgrades.
240,000 WordPress Exploit Attempts
During a full upgrade, WordPress extracts installation files into a temporary folder beneath /wp-content/upgrade/. On vulnerable installations, predictable folder names can let attackers find this separate installer through a web request while the update remains in progress. No existing WordPress account or user interaction is required.
The attack depends on a race condition, meaning the attacker must reach those files at the right moment. The temporary installer must remain accessible long enough to complete the attack before cleanup removes it. This timing requirement makes successful exploitation difficult, even when attackers repeatedly probe known paths.
The official WordPress release announcement confirms that the upgrade weakness can lead to remote code execution. The CVE record classifies it as a time-of-check, time-of-use race condition, with high potential impact on data confidentiality, integrity, and availability.
According to the supplied Wordfence analysis, attackers reaching the exposed installer could complete a staged installation, create an administrator account, and upload malicious PHP code. That access could support backdoors, content changes, or data theft. Observed requests targeted installer files inside predictable upgrade directories.
Wordfence’s supplied figures show attack traffic peaked on October 30, when its firewall blocked more than 74,000 requests. Activity was highest between October 29 and November 1. These figures describe blocked requests, not confirmed infections, successful code execution, or the number of individual websites affected.
Earlier reporting on 60,000 WordPress attack attempts made the same distinction. Repeated automated requests can increase the chance of finding an exposed installer, but request totals alone cannot establish whether attackers completed the required steps or gained lasting access.
Administrators should install WordPress 7.1.4 or the corresponding patched release for their branch. Automatic background updates may have installed the fix, but owners should verify completion. WordPress recommends immediate updating and notes that only its latest release receives active support.
Updating from a vulnerable version still uses its existing upgrade process once. The supplied Wordfence guidance recommends blocking public access to PHP files beneath /wp-content/upgrade/ before updating. Its protection requires Extended Protection mode because staged PHP files run outside normal WordPress loading.
A flaw in ChatGPT let attackers slip past Lockdown Mode, the safety setting meant to stop data leaks. Check Point Research found that a hidden pop-up trick could copy a user’s full chat history, show fake windows, and push malware. In the ChatGPT Classic desktop app, simply chatting was enough to trigger the leak. OpenAI has fixed the bug.
OpenAI launched Lockdown Mode on February 13, 2026, first for business plans. On June 4, it reached personal accounts, where users can turn it on under Settings > Security. The setting limits web browsing to cached pages and turns off live web access, image support in replies, Deep Research, Agent Mode, Canvas networking, live connectors, and file downloads.
OpenAI says it is built for high-risk users, such as executives and security teams, and is not needed by most people. Our earlier story on the ChatGPT Lockdown Mode release covers the basics.
The goal is to stop prompt injection, where hidden text tricks the AI into following an attacker’s orders. A common trick is to make the AI load a link like attacker.example/collect?data= followed by private details. The data then shows up in the attacker’s server logs and the chat looks normal.
In February 2026, OpenAI added an HTML preview to ChatGPT code blocks, so users can view a page right in the chat. That page runs inside two nested iframes, which are small boxed-in web pages. The box blocks outside images, scripts, and links, and it asks the user before anything leaves.
Researcher Alexey Bukhteyev spotted a weak point. The boxes allowed popups through two settings, allow-popups and allow-popups-to-escape-sandbox. ChatGPT guarded popups by swapping out the window.open function. A page could skip that guard by adding one more iframe and calling that iframe’s own window.open.
The popup then opened with no prompt, even in Lockdown Mode. Since the second setting was on, code in the popup ran outside the box.
The first risk was fake update windows. The popup kept the ChatGPT icon, while the attacker chose the title. That made a malware download look like a real app update. In a browser, downloads are not blocked, so a shared chat link was enough, and the victim did not even need an account. In the desktop app, the user still had to click the download link.
The second risk was silent data theft. In ChatGPT Classic, built on Electron, window.open worked without any user click. A malicious prompt, a malicious custom GPT, or a shared chat could then send the whole conversation, and uploaded files, to the attacker’s server.
The third risk was stolen logins. The team also reloaded the main ChatGPT window and signed the user out. A fake login page could then capture the password when the user signed back in.
Check Point reported the problem to OpenAI. On September 18, 2026, OpenAI said it removed both popup permissions from the outer preview iframe. Check Point retested and confirmed the trick no longer works. Check Point published its report on November 5.
No user action is needed for this specific bug, but a few habits lower the risk of similar ones. Do not click buttons, previews, or “update” prompts inside shared chats. Skip prompts copied from unknown sites and avoid custom GPTs from unknown builders.
Check the address bar or sign-in page before typing a password, especially after an unexpected logout. Keep the desktop app updated, and avoid pasting medical, financial, or work secrets into any chat unless needed.
Even OpenAI says its safeguards reduce risk but give no full guarantee. As AI tools run code and show web content, each new feature adds a new way in. Careful habits remain a necessary layer of protection.
Microsoft’s Windows Paint vulnerability, CVE-2026-83844, could allow an unauthenticated attacker to execute code over a network without user interaction.
The flaw carries a CVSS score of 8.1, placing it in the High severity category rather than Critical. However, confusion over the corrected Paint version has complicated patch checks for Windows administrators.
The vulnerability stems from an out-of-bounds read, a memory error in which software reads beyond its intended boundary.
Microsoft published the advisory on October 13, 2026. Its assessment lists a network attack vector, no required privileges, and high attack complexity, meaning successful exploitation depends on conditions that make an attack harder to carry out.
Windows 0-Click Paint RCE Vulnerability
The disclosure formed part of the October update cycle, covered in Cybersecurity News’ Microsoft October Patch Tuesday report. For administrators, the immediate concern is not simply whether an update exists, but whether the corrected application build has actually reached managed devices.
Microsoft initially listed Paint version 11.2605.91.0 as the fixed release. Administrators reported that Microsoft Store continued offering 11.2605.81.0, even after update checks and Store cache resets.
Microsoft’s advisory listed 11.2609.401.0 as the fix, suggesting the earlier version reference may have been incorrect. Microsoft has not confirmed that explanation.
Update availability also appears inconsistent. Some administrators reported difficulty obtaining a corrected build, while one participant in the Reddit discussion said the update had become available through Microsoft Store. These individual reports do not establish a universal rollout status. Claims that availability depends on region also remain unverified.
A crafted image could trigger the flaw, but Microsoft’s quoted guidance describes a crafted network packet sent to an affected service. The Hacker News discussion highlights the missing detail: neither the exposed service nor the complete attack path is identified. Suggestions involving Copilot or other components are speculation.
Administrators should check the installed Paint version rather than trust an “up to date” message alone. Neowin recommends following Microsoft’s current advisory and considering temporary removal where Paint is unnecessary. Restricting untrusted images may reduce general exposure, but it is not a confirmed fix for this specific network attack path.
Cybersecurity News’ separate PNG vulnerability coverage provides related context on image software security. Those flaws are separate from this Paint vulnerability.
Administrators running sshd on Alpine Linux servers are being told to update openssh and restart sshd right away, since upgrading the package alone leaves the old daemon running. A flaw in the OpenSSH server lets attackers log in without a password. Those who cannot patch yet can close the hole by setting PasswordAuthentication to no and restarting sshd.
How the OpenSSH Server Flaw Works
An attacker who can reach the SSH port gets in with a single connection that works every time, with no retries. The attacker needs the name of an account whose password field is * (normal for key-only accounts) plus at least one other account with a $5$ or $6$ hash, then sends a password of 257 to 1,024 bytes. One user with a password exposes every account without one.When built without PAM, sshd hashes each attempt with crypt() and compares it to the stored field, borrowing another account's salt when that field is too short to hold one. musl's crypt() returns * as an error indicator for keys over 256 bytes, which exactly matches the stored field of passwordless accounts. OpenSSH 10.6p2 fixes this, and no CVE had been assigned at the time of writing.
Which Alpine Linux Servers Are Affected
Alpine Linux servers are vulnerable when they run openssh-server (built without PAM) or openssh-server-pam with UsePAM no, keep the default PasswordAuthentication yes, hold at least one local $5$ or $6$ hash, and have an account with a * password field. That includes root, shipped as root:* in the base image since about Alpine 3.16. The default PermitRootLogin prohibit-password shields root unless it is set to yes, but not if another account can become root through doas. Key-only users created with adduser or usermod -p '*', directory users via musl-nscd (nslcd, winbind, sssd), and the tiny-cloud alpine user also count. Every release checked is affected: 3.21 through 3.24, edge, and the older 3.16 to 3.20.Safe setups include containers not running sshd, systems with PasswordAuthentication no or UsePAM yes, locked accounts (user:! in /etc/shadow), machines with no $-style hash, and cloud-init images, which write PasswordAuthentication no.
Patching the OpenSSH Server
Running apk upgrade -U -a, followed by rc-service sshd restart, applies the fix, which ships in Alpine 3.21.10, 3.22.8, 3.23.8 and 3.24.4. Fixed builds are edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1, 3.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7 and 3.16 9.0_p1-r6. Although 3.21 reached end of support on 2026-11-01, patched packages go back to 3.16.For the workaround, root should first confirm key login works and keep the current session open. A drop-in file, /etc/ssh/sshd_config.d/00-no-passwords.conf (read from 3.19 onward), sets PasswordAuthentication no, while a sed command flips every such line in sshd_config, Match blocks included, and saves sshd_config.bak. Running sshd -t && rc-service sshd restart, then sshd -T | grep -i passwordauthentication, should print passwordauthentication no. Deleting the drop-in and restoring the backup undoes it.
Cloud Images and Spotting Attacks on Alpine Linux Servers
Official tiny-cloud images (qcow2, VHD and AMI) from 3.18.11 through 3.24.3 ship an alpine user with a * field and passwordless doas. They are safe on first boot but become exploitable once any $6$ hash appears, such as a console password or a user-data account with hashed_passwd, giving attackers a shell as alpine and then root. Instances from earlier point releases need updating or password logins disabled.Admins should check /var/log/messages for sshd "Accepted password" lines on passwordless accounts and review doas use, new users, files, and authorized keys. If a login cannot be ruled out, the machine should be treated as compromised.Özgün Kültekin of Wakefield reported the issue. Damien Miller and Darren Tucker of the OpenSSH project delivered the fix and the 10.6p2 release; Timo Teräs helped analyze the bug, and Natanael Copa built and uploaded the updated packages.
A flaw in Zyxel GS1900 switches was already being used by hackers, and the patch meant to fix it did not work. Researchers at Binarly found that a public exploit hit a different bug than the one Zyxel had patched. Zyxel has now confirmed it as a new flaw, tracked as CVE-2026-107441.
Zyxel published its fix for CVE-2026-7273 on June 16, 2026. After GreyNoise reported real attacks in September, Binarly tested all ten fixed firmware releases on September 28 and found every one still open. Zyxel confirmed the new bug on October 11, shipped a fix on October 22, and published its advisory on November 3.
The flaw sits in the dispatcher.cgi web program. It carries a 9.8 critical score, and an attacker can run commands as root without logging in. The same weak code also exists in httprestorecfg.cgi and httpupload.cgi.
Zyxel GS1900 Zero-Day Exploited
The switch web page stores request parameters in a fixed memory block of 140 slots. Each slot holds 1,024 bytes. The code copies the data first and checks the count afterward. A long value in slot 139 spills over and overwrites the counter itself.
An attacker can set the counter to a negative number and write to memory before the block. This lets them overwrite function pointers and run their own commands. Zyxel’s patch added a count check, but the bad copy still happens before that check runs.
Binarly also says Zyxel described the bug wrongly. The flaw lives in global memory, not on the stack. It also works over normal HTTP from any network that can reach the switch, so Binarly rates it higher than the 8.8 score Zyxel gave.
GreyNoise says one actor hit 996 GS1900 switches in 48 countries around August 17. The actor stole device settings, hashed root passwords, and network details. A total of 564 of those switches still used factory default logins. Italy, the United States, and Taiwan had the most victims.
The exploit was a Python script hidden with PyArmor. It pulled a collector script from the attacker’s server using TFTP, then copied the stolen data to a web-readable folder. GreyNoise ties the actor to the Gitea campaign that Acronis called Red Heron, based on shared servers and malware.
That campaign used JITTERLY, a Linux backdoor with more than 30 commands. It hides a rootkit called SIXZUT inside itself, which can conceal files, processes, and network links. Binarly found its samples while checking this server for Binarly Transparency Platform detections.
CISA added CVE-2026-7273 to its Known Exploited Vulnerabilities list on September 21. Our earlier report on the CISA warning for Zyxel GS1900 switches covers that step. Binarly now says either Zyxel’s first patch was wrong, or the attacks hit a different bug than CISA named. Either way, the flaw in Binarly’s advisory is present in the ten releases sold as fixes.
Update every GS1900 switch to the October 22 fix or newer from Zyxel. Take web management pages off the internet and limit them to trusted admin networks. Change all default passwords right away.
CISA also tells teams to check devices for odd admin activity, changed settings, and strange web requests. Because attackers took hashed root credentials, treat any exposed switch as possibly stolen and rotate its passwords.
Google has released its November 2026 Android security update, addressing more than 200 vulnerabilities across the operating system, kernel, and hardware components.
Published on November 2, the bulletin includes critical remote code execution flaws that require no user interaction. Devices with security patch level 2026-11-05 or later receive all applicable fixes.
The most serious Framework issue, CVE-2026-58868, could allow remote code execution without additional execution privileges. Google lists fixes for Android 14, 15, 16, 16 QPR2, and 17. The lack of required user interaction makes this a zero-click threat, removing the need to persuade someone to open malicious content.
Two other critical remote code execution vulnerabilities, CVE-2026-58876 and CVE-2026-58936, affect the System component across those same Android releases.
Google describes the most severe System issue as requiring neither additional privileges nor user interaction. However, the bulletin does not provide enough technical detail to establish the precise delivery method for each flaw.
These findings follow earlier Android updates addressing remote attack risks, including the September 2026 Android security update. The November bulletin does not state that its newly listed flaws are being exploited. A zero-click vulnerability describes the interaction required for an attack, not proof that attackers have already used it against users.
The update also covers high-severity information disclosure, privilege escalation, and denial-of-service bugs. Android runtime flaw CVE-2026-58988 could expose information locally without additional execution privileges or user interaction.
Other Framework and System entries could allow attackers to gain greater access, expose protected data, or interrupt services, depending on the specific vulnerability.
Android 0-Click Remote Code Execution Flaws
According to Google’s November Android Security Bulletin, the kernel fixes include critical issues affecting Bluetooth, Human Interface Device support, and protected Kernel-based Virtual Machine components.
Google says the most severe kernel vulnerability could enable remote privilege escalation without additional privileges or user interaction, making these fixes important alongside the platform patches.
Hardware coverage extends to Arm, Imagination Technologies, MediaTek, Unisoc, and Qualcomm components. MediaTek’s entries include eight critical modem vulnerabilities, while Qualcomm’s closed-source section contains another critical issue. These findings do not mean every Android phone contains every affected component. Exposure depends on the device’s hardware, software version, and the fixes supplied by its manufacturer.
The bulletin separates fixes into November 1 and November 5 patch levels. The earlier level covers the listed platform issues, while November 5 includes all applicable fixes from both groups and previous bulletins.
Cybersecurity News’ Android security patch guide explains why checking the patch date matters more than simply checking the Android version.
Users should install available manufacturer updates and check Google Play system updates separately. Google lists several affected Mainline components, including Media Codecs, MediaProvider, Telephonycore, and WiFi. Google’s update guidance explains how Pixel owners can check for software updates. Availability varies by device and carrier, so publication does not guarantee immediate delivery to every supported phone.
Google Play Protect remains useful, particularly for detecting harmful apps, but it does not replace operating system patches. Google’s severity ratings also assume platform protections are disabled or successfully bypassed, rather than guaranteeing exploitation on every device. For administrators, the practical priority is confirming supported devices receive the complete applicable November security update.
Attackers needed less than two days to start going after a freshly patched WordPress vulnerability. The flaw sits in WordPress core itself, and it can let an attacker run code on a website while that site is installing an update.WordPress shipped version 7.1.4 on October 28, 2026, to close the hole. Within 48 hours of that release, exploitation attempts were already underway. Security firm Wordfence said it blocked 62,969 attacks aimed at this vulnerability in WordPress over a single 24-hour period.Anyone running WordPress for a business, a nonprofit, or a healthcare facility is being urged to update right away.
What WordPress 7.1.4 Fixes Beyond the WordPress Vulnerability
Version 7.1.4, released on October 28, is mainly a security release. Alongside the critical code execution fix, it patches several stored cross-site scripting (XSS) flaws, a denial-of-service issue, and two separate information leaks.The update also refreshes WordPress's bundled root certificates after eMudhra revoked its certificates. Of everything in the release, the code execution bug is the one attackers zeroed in on.Aaron Jorbin, who wrote the release announcement, told users to “update your sites without delay.”A GitHub security advisory published the next day described the issue as a timing weakness in the update system. If an unauthorized user moves quickly enough while an upgrade is running, they may be able to execute their own code on the server. No CVE number has been assigned to it so far.
How the Vulnerability in WordPress Works
When WordPress performs a full-package core update, it first extracts the new files into a dedicated directory inside the upgrade folder. According to the advisory, that directory had a predictable name and was reachable from the public web.That combination is the problem. An attacker who requests the right file at the right moment, before WordPress finishes cleaning up, could trick the server into running arbitrary PHP code.Pulling this off is not trivial. The attacker needs four conditions to line up: a full-package update in progress, web access to the temporary folder, a path they can guess, and a short window before the files are deleted. Under controlled conditions, that window may last only a few seconds.
Which Sites the WordPress Vulnerability Affects
The advisory lists every WordPress release from 4.7 through 7.1.3 as vulnerable. It also names the fixed version for each branch, including 7.0.8, 6.9.11, 6.8.12 and 5.9.20.The WordPress project said it backported the patch to all branches still receiving security maintenance, reaching as far back as 4.7. It also stressed that only the newest version is actively supported.Not every site can be taken over through this bug. The risk rises sharply, however, if an attacker hits a site while it is running a full-package update.Smaller websites face extra exposure. Many sit on shared servers with default settings, which makes them attractive targets for cybercriminals.
How Attackers Are Targeting the Vulnerability in WordPress
Wordfence traced the root cause to full-package upgrades repeatedly using web-accessible paths that are easy to guess. Alex Thomas, a threat analyst at Wordfence, said attackers quickly understood the race condition and turned their attention to it.Two of the biggest attack sources reportedly kept polling small groups of websites for roughly 14.5 hours. Other sources tried out different folder names and version names.The pattern looks like large-scale automated guessing rather than attacks on chosen victims. So far, no confirmed reports have put a number on how many sites have actually been compromised.
How Serious Is This WordPress Vulnerability?
Sources disagree on how severe the flaw is. The Hacker News gave it a CVSS score of 8.1, which falls in the high range. The GitHub advisory, by contrast, rates it as low severity.That gap most likely comes down to how hard the bug is to exploit successfully. Even so, the sheer volume of attack attempts and the simplicity of the fix make it sensible to treat this as a serious threat.
What Comes Next for This Vulnerability in WordPress
The probing is unlikely to stop soon. Once a vulnerability is patched, the fix itself becomes a detailed roadmap for anyone hunting sites that have not been updated.The WordPress project says backports to older branches are still in progress. The next major release, WordPress 7.2, is scheduled for December 8.The advisory credits researcher Umut Bayram with discovering the flaw and reporting it responsibly. There is currently no alternative workaround, so applying the patch is the only fix available.
A newly disclosed TeamViewer vulnerability could let an attacker turn a routine remote support session against the technician providing help. Tracked as CVE-2026-111585, the flaw allows a malicious remote computer to crash the viewer application and potentially run code on the technician’s machine. TeamViewer rates it High, with a CVSS score of 8.8.
Remedio researcher Omri Dar published the technical findings on October 29, following a fix released on October 27. The attack requires the victim to establish a remote session with an attacker-controlled or compromised host. After that connection, no further click or stolen password is needed, according to Remedio.
TeamViewer Security Vulnerability
TeamViewer separates a session into a host sharing its screen and a viewer displaying it. Here, the host attacks the viewer by sending crafted screen data through the same connection used for support. This reverses the expected risk, placing the technician’s computer in danger.
The host sends a DisplayParams message containing screen width, height, and color depth. The viewer uses these values to reserve memory for incoming pixels inside an object called CBitmapBuffer. A malicious host can force this processing path by refusing AV1 and H.264 video options, making the viewer use bitmap updates instead.
The findings expand on the TeamViewer remote desktop vulnerabilities previously reported, but identify the precise calculation error behind this attack. The buffer size is calculated using 32-bit arithmetic. Oversized screen dimensions make that calculation wrap around, leaving much less memory than the viewer expects.
In Remedio’s example, a screen measuring 32,768 by 32,768 pixels at 32 bits per pixel should require more than 4.29 billion bytes after padding. Instead, the calculation reserves roughly four megabytes. The viewer still treats that small buffer as large enough for the announced screen.
The decoder checks incoming image rectangles against the declared screen dimensions, not the actual memory allocation. A rectangle can therefore pass validation while its pixels spill beyond the buffer. These writes damage nearby heap memory, causing a repeatable crash and creating a route toward code execution.
Remedio reported running chosen code on Windows while bypassing Control Flow Guard and Data Execution Prevention. However, its demonstration used a host-side hook to place the corrupting bytes, standing in for the network payload and heap preparation. That detail matters when assessing how complete the demonstrated attack was.
Affected Versions and Available Fixes
TeamViewer’s security bulletin TV-2026-1011 lists affected Full Client versions before 15.83 on Windows, Linux, and macOS, Windows Portable, and Android Remote Control. Code execution depends on the platform and runs with the viewer process’s permissions. It does not automatically mean SYSTEM or root access.
Administrators should install version 15.83 or the latest available release. Legacy deployments need the matching fixed maintenance build listed in the bulletin. This update follows earlier TeamViewer security patches, making checks important across support workstations, portable copies, and older installations that might remain outside normal update routines.
TeamViewer reported no known active exploitation when its bulletin was published. Remedio disclosed the issue on August 14. For support teams, the immediate priority is updating the viewer before connecting to untrusted computers, rather than relying on session approval alone.
Palo Alto Networks has confirmed that attackers are actively exploiting PHP2Shell vulnerabilities against PAN-OS management interfaces exposed to the internet. In its October 29, 2026, update, Unit 42 said it independently verified attacker tools used to combine the PHP flaws with a Linux kernel vulnerability and gain root access.
The vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each carry a critical CVSS 4.0 score of 9.2. They can allow remote code execution without a login. Palo Alto said roughly 0.02% of its global installed base had public management interfaces configured and was impacted. Its teams have contacted those customers individually, according to the Unit 42 threat brief.
The confirmation updates the earlier picture covered in Cyber Security News’ report on PHP vulnerabilities affecting PAN-OS, when the vendor had not reported malicious exploitation against its products.
PHP2Shell Enables Remote Code Execution
Both flaws involve unsafe memory handling when PHP stops processing a request after an error. CVE-2026-109618 affects out-of-memory handling through longjmp(), a function that jumps out of the current operation. That sudden exit can leave request data partly initialized. Cleanup routines may then read or act on that invalid data, creating a path to code execution.
CVE-2026-109619 leaves shared internal state pointing to memory that PHP has already freed. A later request handled by the same worker can reach those stale references before normal setup resets them. Attackers can use this condition to make the process execute their code.
The PHP Group’s security advisory identifies PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed deployments as exposed. Fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Unit 42 counted more than 22.6 million exposed instances potentially vulnerable worldwide. That figure describes possible PHP exposure, not confirmed breaches or affected Palo Alto firewalls.
Dream Research reported finding campaign artifacts showing 25 compromised PAN-OS firewall and management servers across the United States, Japan, Taiwan, and South Korea. The count included three systems in a US government-affiliated environment.
The attacker used a custom PHP2Shell implementation aimed at the PAN-OS management web server. Crafted upload requests created memory pressure, leaked an address, and manipulated memory structures to execute commands as the restricted nobody user. A separate Linux kernel flaw, Fragnesia, tracked as CVE-2026-46300, then enabled root access.
Cyber Security News’ report on the 25-server campaign explains the wider impact. Dream found evidence of webshell placement, internal tunneling, LDAP credential extraction, and Active Directory enumeration. However, it could not confirm whether later password spraying or attempts to create backdoor accounts succeeded.
This confirmation should not be confused with Unit 42’s retracted October 23 update. That earlier account linked activity at a European government agency to PHP2Shell, but investigators could not establish that these specific flaws provided initial access. The October 29 update separately confirms the PAN-OS campaign.
PAN-OS Patches and Immediate Protection
Palo Alto’s security advisory limits the affected surface to the management HTTPS interface and XML API. PA-Series and VM-Series firewalls and Panorama are covered. GlobalProtect portals, gateways, Clientless VPN and Captive Portal are not affected by these PHP flaws. A dataplane interface is exposed only when a management profile is attached.
Administrators should immediately remove public management access, allow only trusted internal IP addresses, and install the correct PAN-OS hotfix. Fixed options include 12.2.4-h1, 12.1.10-h3, 11.2.16-h1, 11.1.16-h4 and 10.2.18-h13, with additional fixes for other maintenance releases. Palo Alto says these updates address both PHP vulnerabilities and interrupt the observed chain.
CISA has added the Node2Shell flaw, tracked as CVE-2026-111497, to its Known Exploited Vulnerabilities catalog. Attackers are already sending live exploit traffic at Node.js servers, so teams should patch right away.
CISA added the bug to its Known Exploited Vulnerabilities catalog on October 27, 2026. Federal agencies must fix it by November 10, 2026. CISA lists it as an unchecked return value flaw in Google Brotli. It says a remote attacker with no login can use a crafted Brotli stream to corrupt memory, leak data, crash the app, or possibly run code. CISA marks ransomware use as unknown. It also says forensic triage is not required under BOD 26-04.
The flaw goes by several names. Researchers call it Node2Shell, HTTP2Shell, Broccoli2Shell and Brotli2Shell. Google’s CNA gives it a 9.2 Critical score under CVSS 4.0. The bug is an out-of-bounds write in the Brotli decoder, and Wiz’s technical write-up covers detection and mitigation for cloud teams.
Our own earlier report on the Node2Shell proof of concept covered the first public code execution demo. Things have moved fast since then. Within days, the story went from a lab demo to real attacks.
Node2Shell Vulnerability
Brotli is a compression format that web servers and clients use to shrink traffic. A Brotli stream is split into blocks, and special switch commands tell the decoder which block type comes next. The trouble starts when a kind of block has only one type declared.
A switch in that case is invalid and the decoder should reject it. ELLIO’s research explains that the helper function returned a plain false for this case. It also returned false when the decoder simply ran out of input. Two different problems got the same answer.
When the caller hears that more input is needed, it sends more. The decoder keeps leftover bytes in an internal eight-byte buffer. A real shortage drains that buffer on the next chunk. An invalid switch never drains it. The bytes keep piling up, and past the eighth byte the writes land outside the buffer. Because the write uses a signed 32-bit offset, an attacker can pick a spot within roughly 2 GB and copy 16 bytes of their own data there.
The fix is upstream commit 0ed4268a. It makes the helper return a real error code, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH with value -17, so bad streams stop at once. The bug has been in Brotli since version 1.0.3 in March 2018. ELLIO says the fix sat in the public master branch from February 2026 with no release or advisory for about eight months.
Who Is Affected
Node.js 22.x, 24.x and 26.x are hit, and so are the end-of-life 20.x, 23.x and 25.x lines. The old lines will get no fix. Fixed Node.js versions are 22.23.4, 24.22.1, and 26.12.1. Google fixed Brotli in 1.0.10, 1.1.1, and 1.2.1.
A bare Node.js server does not unpack a Brotli body just because it arrives. Something has to pass the bytes to the decoder. ELLIO describes three common paths. The first is an inbound request with Content-Encoding set to br. Express 5 with express.json() or express.raw(), body-parser 2 and Koa with @koa/bodyparser all unpack it before any route code runs.
The second is an outbound fetch. Built-in fetch(), axios, got, and SuperAgent will decode a hostile server’s reply, so link previews, webhooks, and crawlers are all at risk. The third is any direct node:zlib call on client data.
The problem reaches well past Node.js. Bun before 1.4.4 is affected, and so are the Python packages Brotli and brotlicffi, which need 1.2.1 and 1.2.1.0. Envoy, the Ruby brotli gem, and many Linux distributions are also on the list. The CIS advisory says the flaw sits in Google Brotli versions 1.0.3 through 1.2.0 on all platforms. Tenable’s FAQ lists affected products in one place.
One trap is worth knowing. Node.js cherry-picked the fix without changing the bundled version string. So process.versions.brotli shows 1.2.0 on both patched and unpatched builds. Check the Node.js release number instead.
Imperva’s Red Team showed the first working exploit on October 22. They ran code on the official Node.js 24.22.0 Linux arm64 image, using both fetch() and Express 5 request bodies. Their write-up, Node2Shell: From Brotli Data to Remote Code Execution, says version 24.22.1 rejected the same input.
ELLIO then repeated the attack on x86-64. It got a shell on four targets running the same build. These were a plain node:http server, the official node:24.22.0-slim image running as root, Express 5.3.0, and Koa 3. Each shell ran as the service’s own account.
The lab found that official Node.js builds are non-PIE, so the binary loads at the same address every time. Address space layout randomization still shuffles the heap and stacks, so an attacker has to guess. With ASLR on, a shell appeared at around attempt 5. With ASLR off, 60 attempts gave no hit. Turning it off does not help.
Two target-specific values decide success. One is the number of the accepted socket, which the shell uses for input and output. The other is a memory offset tied to one exact Node.js build. The offset for 24.22.0 gave nothing against 22.23.3 or 26.12.0 in 10,000 tries. That limits attackers to waves aimed at one popular build at a time.
Scanning began first. A checker calling itself node2shell-check/1.0 hit ELLIO’s sensors from AS44620. It sent 20 Brotli bodies in two bursts to find hosts that decompress Brotli at all. None carried the real trigger. This looked like list building ahead of an attack.
Exploit traffic followed on October 26 at 15:08 UTC. ELLIO saw a single 23,069,983-byte request with SHA-256 7fcbdaaecd4419e2930927844f3b772668204737a4e7602a2290c991c93c5c4b. It came from 94.154.43.7, an address ELLIO rates as malicious with high confidence.
The address was first seen in December 2025 and was active on 47 of the last 90 days. It has been tied to PHP2Shell exploitation, Palo Alto GlobalProtect and FortiOS SSL VPN probing, and Kubernetes scanning. The request targets only Node.js v24.22.0 on x86-64.
The delivery layer copies public exploit code. The ROP chain, which takes over the process, is original. It plants /bin/sh in its own data and calls Node’s execvp from there. It does not use the string already inside Node, as both public chains do.
ELLIO tested it against a clean vulnerable target and got zero shells in 50 attempts. The chain crashed the process instead. ELLIO thinks this was a first try fired before the operator tested the last step. It warns that the operator looks focused on mass exploitation. Teams that remember React2Shell will see the same pattern of fast public code followed by quick scanning. Microsoft documented that earlier flaw in its React2Shell defense guide.
Failed attempts are not harmless. ELLIO saw that most of its 400 Express attempts crashed the worker instead of giving a shell. A crash can write a core dump, and that dump may hold session cookies, tokens and keys from other visitors.
On a stock Ubuntu host, systemd-coredump saves these files in /var/lib/systemd/coredump. Containers usually write nothing, so the harm there is only downtime. Some other decoders hang quietly instead. Python Brotli 1.2.0, brotlicffi 1.2.0.0, the PHP streaming API and the Ruby gem all return nothing and never finish, and the PHP case spins at 100% CPU.
Patch first. Move Node.js to 22.23.4, 24.22.1, or 26.12.1, and update Bun, Python packages, Envoy, and any distro Brotli library. Debian users should look for DLA-4855-1 or DSA-6582-1. Alpine users need brotli 1.2.1-r0, or 1.1.1-r0 on 3.21. Leave the old 20.x, 23.x and 25.x lines behind, since they will never be fixed.
A Node.js upgrade only fixes the copied Node bundles. Tools with their own copy, like bun build –compile executables, DuckDB, and PHP extensions, need separate updates. Rebuild images, refresh lockfiles, and restart processes.
A Dockerfile that pins 24.22.0 keeps shipping the bad build until someone edits that line. Check staging, CI, serverless, and developer laptops too.
Until patching is done, block inbound Content-Encoding: br where you can. Also watch logs for large Brotli POST bodies, repeated worker crashes, and the IP and hash above. Limit who can read core dumps, and shorten how long you keep them. Federal teams face the November 10 deadline, but every other team should treat that date as a ceiling and not a goal.
OpenSSL has released version 4.1.0, bringing DTLS 1.3 support, faster cryptographic operations, and new tools for developers building secure network services.
Published on October 23, the update is a feature release, not a standalone security patch. It also includes compatibility changes and four known issues that teams should review before deployment.
The official release notes identify DTLS 1.3 as a key addition. The release follows the earlier OpenSSL 4.1.0 Alpha1 preview, which introduced the protocol alongside GREASE support and cryptographic performance improvements.
Datagram Transport Layer Security protects applications that use transports such as UDP. Unlike TCP, UDP does not guarantee that packets arrive or arrive in order.
DTLS adds encryption and authentication while preserving that behavior, making it useful for applications where delays matter, including gaming and some streaming services.
OpenSSL 4.1.0 Released With DTLS 1.3
Defined in RFC 9147, DTLS 1.3 builds on TLS 1.3 and helps prevent eavesdropping, data tampering, and forged messages. It provides similar security guarantees, but applications must account for differences in message ordering and replay protection. DTLS also handles lost handshake messages without turning application traffic into a reliable, ordered stream.
OpenSSL 4.1.0 adds DTLS support to its SSL listener API. Other additions include GREASE, the IKEv2 key derivation function, and initial support for the Elbrus2000 processor architecture. GREASE stands for Generate Random Extensions And Sustain Extensibility.
The release improves ML-DSA and ML-KEM number theoretic transform operations on ppc64le systems. On x86_64, it adds optimized ML-DSA operations, AVX-512 SHAKE processing for ML-DSA, and AVX-512 and VAES improvements for AES-CBC decryption. The release notes provide no benchmark figures.
Developers using the tsget utility must install Net::Curl::Easy before upgrading because it replaces the abandoned WWW::Curl::Easy dependency. OpenSSL also removes Windows-on-Itanium and Windows CE build targets while adding targets that address gaps in MSVC 2013’s C99 support.
The no-ecdsa and no-ecdh configuration options have been removed because they didn’t actually turn off those implementations. Teams seeking to turn off elliptic curve support must use no-ec instead.
Four documented problems affect DTLS behavior. Receiving a DTLS 1.3 KeyUpdate can remove other pending post-handshake records from the retransmission buffer. If the original packets are lost, records such as session tickets will not be resent. A fix is planned for a future release.
Listener error handling also has limitations. A permanent receive failure may appear as SSL_ERROR_WANT_READ, leaving applications waiting.
A retryable write failure may instead appear as SSL_ERROR_SYSCALL, potentially causing applications to close usable connections. Early client acknowledgments can also trigger handshake failures after packet loss.
Teams should test these paths before rollout. Earlier OpenSSL DTLS memory-leak coverage provides useful security context. However, those patched flaws are separate from the known issues documented for this release.
Oracle has released an emergency Java security update to address CVE-2026-91403, a critical vulnerability affecting how Java applications trust digital certificates. Published on October 21, 2026, the alert assigns the flaw a CVSS 3.1 score of 9.1 and covers Oracle Java SE and GraalVM. The update blocks affected intermediate certificate authority certificates linked to eMudhra.
According to Oracle’s security advisory, the issue affects the Java Secure Socket Extension, or JSSE, component. Oracle rates exploitation as low complexity, with no authentication or user interaction required. Successful attacks can expose or change sensitive data, although the risk matrix lists no availability impact.
The problem involves certificate chains that Java uses to decide whether a remote service is trusted. Red Hat explains that eMudhra issued intermediate certificates with weak private keys. An attacker positioned between a Java client and a server could use those weak keys to create certificates for arbitrary hostnames, making a malicious site appear trusted.
This undermines the identity checks behind HTTPS. Encryption alone cannot protect a connection when the client accepts an attacker’s certificate as valid. The fix therefore changes which certificates Java accepts, rather than removing HTTPS support or replacing the entire certificate system. Oracle’s update specifically distrusts the impacted intermediate certificates.
Affected Java and GraalVM Versions
Oracle lists Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, and 27.0.1 as affected. GraalVM for JDK 17.0.21 and 21.0.13, alongside GraalVM Enterprise Edition 21.3.20, are also included. Earlier releases may be vulnerable, but unsupported versions were not tested.
Oracle notes that affected APIs can be reached through services supplying data to JSSE. Its advisory also covers certain sandboxed Java Web Start applications and applets that load untrusted code. The announcement does not report confirmed attacks exploiting this vulnerability.
Oracle recommends installing the latest Java update or following its eMudhra mitigation instructions. Teams unable to update immediately can replace the local blocked.certs file with Oracle’s supplied version, preserving existing custom entries. Java 8 requires the replacement file to be named blacklisted.certs.
Alternatively, Oracle advises enabling TLS revocation checks using -Dcom.sun.net.ssl.checkRevocation=true and -Dcom.sun.security.enableCRLDP=true. For signed JAR verification on JDK 17 and later, it provides jarsigner -verify -revcheck -strict [SIGNED_JAR]. These are alternatives, not steps that must all be applied together.
The emergency alert follows Oracle’s wider patching efforts, including its September security update and August security patches. However, administrators should check this specific advisory rather than assume earlier updates cover the certificate issue. Oracle directs customers to its patch availability document for installation details and recommends moving unsupported deployments to supported releases.
Fortinet has urged customers to prioritize security updates for FortiOS, FortiManager, and FortiAnalyzer scheduled for October 22, 2026. The coordinated release addresses critical and high-severity vulnerabilities, including flaws found through AI-assisted security testing. The company said customers should address internet-facing devices first.
In an October 21 announcement, Fortinet Chief Information Security Officer Carl Windsor warned customers against treating these fixes as routine maintenance. The update follows security releases for FortiMail and FortiAuthenticator, extending the patching effort across several key products.
Fortinet said its testing program uses advanced AI models to examine code paths, protocol handling, and configuration logic. The company thanked Anthropic, OpenAI, Google, and SpaceX for their work with its security teams.
The concern extends beyond finding new bugs. Fortinet warned that attackers can use AI to compare patched and older software, identify changed code, and build exploits within hours or days. This process, known as patch diffing, can expose weaknesses before customers finish upgrading.
AI may also help attackers combine lower-severity flaws into a more serious attack chain. However, the announcement does not provide individual CVE identifiers, CVSS scores, or detailed attack conditions for this release. It also does not report active exploitation of these newly addressed flaws.
Its earlier testing report also stressed human review. Security analysts validate AI findings and test whether they are exploitable, helping separate real vulnerabilities from false alarms and recommend product security improvements.
Affected Versions and Required Updates
FortiOS customers should move to version 8.0.2, 7.6.8, 7.4.13, or 7.2.14, depending on their current branch. Affected releases span 8.0.0–8.0.1, 7.6.0–7.6.7, 7.4.0–7.4.12, and 7.2.0–7.2.13.
FortiManager and FortiAnalyzer share the same minimum fixed releases: 8.0.2, 7.6.8, 7.4.12, and 7.2.13. Their affected versions cover 8.0.0–8.0.1, 7.6.0–7.6.7, 7.4.0–7.4.11, and 7.2.0–7.2.12. Fortinet lists October 22 availability for all these updates.
For FortiMail, the fixed versions are 8.0.2, 7.6.7, and 7.4.9. Customers running affected FortiMail 7.2 releases must move to the 7.4 branch or later. FortiAuthenticator users should install 8.0.4 or 6.6.11, depending on their branch.
Product
Release Branch
Affected Versions
Patched Version or Required Upgrade
FortiOS
8.0
8.0.0–8.0.1
8.0.2 or later
FortiOS
7.6
7.6.0–7.6.7
7.6.8 or later
FortiOS
7.4
7.4.0–7.4.12
7.4.13 or later
FortiOS
7.2
7.2.0–7.2.13
7.2.14 or later
FortiManager
8.0
8.0.0–8.0.1
8.0.2 or later
FortiManager
7.6
7.6.0–7.6.7
7.6.8 or later
FortiManager
7.4
7.4.0–7.4.11
7.4.12 or later
FortiManager
7.2
7.2.0–7.2.12
7.2.13 or later
FortiAnalyzer
8.0
8.0.0–8.0.1
8.0.2 or later
FortiAnalyzer
7.6
7.6.0–7.6.7
7.6.8 or later
FortiAnalyzer
7.4
7.4.0–7.4.11
7.4.12 or later
FortiAnalyzer
7.2
7.2.0–7.2.12
7.2.13 or later
FortiMail
8.0
8.0.0–8.0.1
8.0.2 or later
FortiMail
7.6
7.6.0–7.6.6
7.6.7 or later
FortiMail
7.4
7.4.0–7.4.8
7.4.9 or later
FortiMail
7.2
7.2.0–7.2.9
Upgrade to the 7.4 branch or later
FortiAuthenticator
8.0
8.0.0–8.0.3
8.0.4 or later
FortiAuthenticator
6.6
6.6.0–6.6.10
6.6.11 or later
Fortinet plans to publish public advisories on its PSIRT page on November 10. Its notice says FortiSASE will receive automatic updates before the coordinated release. FortiManager Cloud updates may require manual action, while public cloud updates follow the relevant cloud provider’s release process.
The gap between firmware availability and full public disclosure gives customers time to upgrade before detailed advisories appear. It does not mean exposed devices can safely wait until November. Fortinet explicitly asks customers to act when the updates become available, rather than delay for technical details.
PHP and Node.js Add Patching Pressure
The warning comes alongside separate PHP and Node.js security releases. These are distinct issues, not confirmed components of the Fortinet vulnerabilities.
PHP released emergency patches on October 21 for CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. Both can allow remote code execution without authentication. One involves memory exhaustion leaving incomplete request data, while the other involves stale request state surviving after memory is freed.
Cybersecurity News’s PHP2Shell coverage explains the risks across different server setups. Fixed PHP releases are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The PHP Foundation also described how AI-assisted research contributed to investigating these weaknesses.
Separately, the Node.js security update addresses ten vulnerabilities, including four rated high severity. CVE-2026-111497 affects Brotli decompression and can allow code execution through an out-of-bounds memory write. Other high-severity fixes address TLS hostname verification bypasses and DNS name truncation. The affected supported branches are 26.x, 24.x, and 22.x.
Fortinet recommends identifying exposed systems, backing up configurations, and scheduling urgent maintenance windows for October 22–23. Teams should review logs for unusual administrator access and unauthorized configuration changes before and after patching.
Where upgrades cannot happen immediately, administrators should restrict HTTPS and SSH management to trusted addresses, remove FortiManager administration from the public internet, and enforce multifactor authentication with unique passwords. These controls reduce exposure but do not replace installing the security updates.
Governments and cyber-security agencies worldwide are urging website operators to patch PHP2Shell, two critical PHP flaws tracked as CVE-2026-109618 and CVE-2026-109619. Found with AI, the bugs enable remote code execution and Heartbleed-style memory disclosure. A fix arrived on Wednesday afternoon.
Several agencies told organizations unable to patch in time to consider pulling their sites. Finland temporarily shut its government’s public web services. In the Netherlands, the cyber-security agency, the National Institute for Public Health and the Environment, and the Tweede Kamer, parliament’s lower house, all went offline.
The US National Security Agency echoed this on X: “These vulnerabilities often provide a direct path to the server’s file system or database.” The White House said federal agencies were working with leading AI labs to speed up a fix, while Japan’s Prime Minister Sanae Takaichi urged people on X to check whether their public websites ran on PHP.
“We have taken down a number of other systems as a precautionary measure until they can be safely patched,” the Wikimedia Foundation said, leaving parts of Wikipedia unreachable on Wednesday. Edinburgh council’s website and pages for BBC programmes, including Doctor Who and The Traitors, also went dark, though neither has confirmed a PHP link. DeviantArt said only that it was “temporarily down for maintenance.”
How AI found CVE-2026-109618 and CVE-2026-109619
Researchers at Calif and Wiz uncovered the flaws. Calif and the PHP Foundation were part of OpenAI’s Patch the Planet program, which offered AI tools to find and fix PHP flaws. Wiz called them the “most severe vulnerabilities ever discovered” by AI. OpenAI described them as “one of the most impactful security issues in recent memory,” adding that its own researcher spotted the issue around the same time.
The bugs sat undetected for over a decade before surfacing August, after a few weeks of AI-assisted work. “Frontier models were critical to making this process practical, enabling us to develop and adapt working exploits across multiple applications in hours,” Wiz said. It estimates “roughly 70%” of the internet is affected; a figure not independently verified.
The PHP Foundation planned to disclose PHP2Shell later this month with a full patch, but details leaked on social media on Tuesday, forcing a rushed announcement.
Early PHP2Shell Attacks Emerging
The UK’s National Cyber Security Centre (NCSC) and its EU and Australian counterparts urged PHP users to apply the fixes. “Where immediate remediation is not feasible, organizations should consider taking the system offline until it can be fully mitigated,” the NCSC said. Japan’s national cyber-security office and EU officials issued similar warnings.
“PHP is everywhere. It quietly powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels, and an awful lot of software that doesn’t even advertise that it runs PHP under the hood,” said security firm Huntress.
Affected versions remain unclear, though CERT-EU said CVE-2026-109618 and CVE-2026-109619 could reach back to PHP 5, launched in 2004. The update covers only the latest versions; users on PHP 8.1 or older should upgrade. Built for web development, PHP runs server-side on a large share, though not all, of the internet.
Verify you are human
Checking your browser before accessing this site.
Click to verify →
Then you will be redirected to the requested content. Ray ID: 8f3a2c1b9d4e5f6a · Performance & security by Cloudflare
Cloudflare says it is seeing early attempts to exploit two critical PHP vulnerabilities whose details surfaced before the PHP security team’s planned release. The company has deployed an initial set of Web Application Firewall (WAF) rules to block known exploit patterns. Cloudflare says the rules are available to all customers, including those on free plans, and that it is updating them as new patterns appear.
The warning raises the urgency for teams running PHP websites, but the firewall rules are only a temporary layer of protection. Cloudflare’s chief technology officer, Dane Knecht, said customers should patch as soon as PHP publishes its security update. At the time of writing, the release is scheduled for 14:00 UTC on October 21, or 19:30 IST.
PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free.
We are seeing early attacks emerging and are updating mitigations as new vectors show… https://t.co/wMz9tDTWwH
Public reports track the flaws as CVE-2026-109618 and CVE-2026-109619. The PHP security team has rated both critical, with a CVSS v4.0 score of 9.2. Researchers and security reports describe them as remote code execution vulnerabilities, a type of flaw that could let an attacker run code on a vulnerable server. However, PHP has not yet published full technical details, including the affected components, precise attack paths, or confirmed vulnerable versions.
The information became public before the planned disclosure and security update. The PHP team announced an earlier release date after the leak, and said it could move the release forward again if technical details became public or it found evidence of active exploitation. Cloudflare’s warning now indicates attempts are emerging, although the company has not shared evidence or details that would allow readers to assess their scale or success.
A WAF checks web requests and can block traffic that matches known harmful patterns. These rules can reduce exposure while administrators prepare updates, but they cannot replace fixes to the underlying PHP code.
New PHP2Shell exploit patterns may also evade rules written for known requests. Cloudflare says it is adjusting its protections as new vectors appear, but it has described the rules as a stopgap.
Organizations should identify every internet-facing system that runs PHP, including sites built with content-management systems and software that bundles its own PHP runtime. Administrators should monitor PHP’s official security notices and their operating-system or hosting provider’s update channels.
Once fixed releases are available, they should verify the affected versions and apply the right update promptly. Teams should also check that their WAF is enabled and that relevant rules are set to block, not merely log, suspicious requests, as Cloudflare has advised paying customers.
After patching, defenders should review web-server and PHP logs for unusual requests and check whether PHP worker processes launched unexpected programs. Security teams should investigate suspicious activity rather than assuming that a WAF block means a system was never reached. If a server shows signs of compromise, preserve logs and follow the organization’s incident-response process.
The incident also shows how a vulnerability disclosure leak can compress defenders’ preparation time. PHP’s broad use across websites and hosting services means administrators may need to locate runtimes outside their main application inventory.
Reports say the flaws may affect older PHP versions, but the official affected-version list is still pending, so organizations should avoid relying on preliminary claims.
A public proof-of-concept repository shares verification tools and a lab setup to test two critical PHP vulnerabilities known as php2shell. The flaws, tracked by researchers as CVE-2026-109618 and CVE-2026-109619, are reported to affect PHP’s session.upload_progress feature and could lead to remote code execution under certain conditions.
The release adds technical detail to a fast-moving security issue. PHP’s security team announced that an emergency release would address two critical vulnerabilities, each rated 9.2 under CVSS v4.0, and urged users to prepare to upgrade.
Its notice scheduled the release for October 21 at 14:00 UTC. At the time of writing, that release time has not yet passed, so PHP’s official notice has not confirmed the technical details, affected versions or fixed builds described in the research repository.
The repository says the vulnerabilities affect PHP versions 5.4.0 through 8.5.11. It lists PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 as planned fixed versions, but administrators should verify these against the PHP team’s release advisory before updating. The PHP project’s advance notice confirms the severity and planned release, but not those version details.
PHP branch
Current support status
PHP 8.2
Security fixes only
PHP 8.3
Security fixes only
PHP 8.4
Active support
PHP 8.5
Active support
These are the branches eligible for official security updates. PHP 8.1 and older—including PHP 8.0, 7.x, and 5.x—are end-of-life and will not receive official PHP project fixes.
PHP2Shell Vulnerability PoC Exploit
The researcher’s write-up describes several paths to code execution, rather than one universal exploit that works against every PHP website. One chain combines session-file injection with a local file inclusion flaw in an application.
According to the repository, this path depends on upload progress being enabled and an application flaw that allows a local file to be included. A local file inclusion bug occurs when an application can be made to load a file from its server in an unintended way.
The repository says PHP’s upload-progress handler stores a supplied filename in session data without validating it. It also reports that a session identifier sent in a POST body can bypass the session.use_only_cookies setting, which is meant to restrict how session IDs are accepted.
These claims describe how a weakness in PHP’s session handling could combine with a separate application bug. They should not be taken to mean that every PHP site is immediately exploitable through this route.
A second reported issue involves a use-after-free, a memory error that can occur when software continues to use data after it has been released. The researcher says that re-entry into a var_destroy destructor can trigger this condition and reports confirming it with AddressSanitizer, a tool used to find memory errors.
The repository also describes a PHP-FPM serializer state that may persist across requests, and a handler mismatch that may cause a destructor to run after deserialization fails. The researchers say some of these paths need additional conditions, such as an application gadget or access to a local file.
These technical claims remain those of the independent research project until they can be compared with PHP’s full advisory and patches. Security teams should avoid treating every listed path as independently confirmed for all versions or configurations. The project’s verification repository provides the research overview and lab files. Its stated purpose is controlled testing, not use against systems without permission.
PHP runs a wide range of websites and applications, so a flaw in its core session handling could affect many types of deployments. The risk can be greater when an application already has a file inclusion weakness or unsafe deserialization behavior.
Mallory report highlights the scale of outdated PHP deployments as administrators prepare for the php2shell security updates. Using Shodan data collected on October 20, the company identified 883,717 internet-facing hosts running PHP 8.1 or earlier.
These represent about 59% of the roughly 1.5 million hosts that disclosed a PHP version. Those branches no longer receive official PHP project security fixes, making migration to a supported release a key concern.
PHP hosts Counts (Source: Mallory)
As previous PHP security coverage has shown, memory errors in PHP components can have a serious impact, though the technical causes differ. This report also covers another example of application-level risk on ScriptCase vulnerabilities.
The reported score of 9.2 signals a critical issue, but it does not tell administrators whether a particular server is exposed. That depends on the PHP version, configuration, application behavior, and whether the necessary conditions for a specific chain exist. The public repository includes a PHP-FPM and Nginx lab for testing. Organizations should use such environments only for authorized validation and should not run proof-of-concept code against production systems.
Administrators should inventory PHP installations across web servers, containers and managed hosting environments, then check the official PHP security release for confirmed affected and fixed versions. Once a suitable update is available, apply it promptly and restart PHP-FPM or the relevant web service so the new binaries take effect.
Systems running end-of-life PHP branches require special attention because they may not receive official fixes. The repository identifies PHP 5.x, 7.x, 8.0 and 8.1 as unsupported, but teams should confirm support status with the PHP project.
The researcher lists disabling session.upload_progress and setting session.use_only_cookies to On as temporary safeguards. These settings may reduce exposure to some reported paths, but the repository warns that they do not address every attack chain.
They are not a substitute for a security update. Review applications for local file inclusion and unsafe deserialization issues, and check server logs for unusual requests involving PHP session handling while the official advisory is being reviewed.
For now, the public proof-of-concept is best treated as a signal to prepare and validate safely. The key next step is to compare the research claims with PHP’s official release details, then patch affected systems as soon as the project publishes confirmed fixed versions.
Ransomware operators are exploiting a Palo Alto Networks GlobalProtect VPN flaw to bypass multi-factor authentication and enter corporate networks. In one investigated case, attackers reached VMware management systems and stole credentials directly from a domain controller’s virtual disk, avoiding security tools running inside the virtual machine.
Palo Alto Networks Unit 42 detailed the activity in an October 19 threat brief update. Researchers linked exploitation of CVE-2026-0257 to Spikey Scorpius, also known as Qilin, and Tarnished Scorpius, also known as Inc. Separate public reporting connected exploitation to operators using Settra ransomware.
Investigations ongoing since early June have covered healthcare, education, financial services, manufacturing, government, energy, and other sectors. The latest findings show how unauthorized VPN access can develop into credential theft, data theft, and ransomware deployment.
GlobalProtect Flaw Bypasses MFA
The vulnerability affects GlobalProtect portals and gateways in certain PAN-OS and Prisma Access deployments. Exposure requires authentication override cookies to be enabled alongside a vulnerable certificate setup. Palo Alto Networks rates the flaw High, with a CVSS score of 7.8 and its highest suggested response urgency. Panorama and Cloud NGFW are not affected.
Authentication override cookies let previously authenticated users reconnect without repeating the full login process. According to Rapid7’s technical analysis, vulnerable devices decrypt these cookies but do not properly verify that a trusted system created them.
If the cookie certificate is reused for a publicly exposed service, attackers can obtain its public key and forge a cookie. The gateway may accept that cookie as proof of authentication, allowing a VPN connection without the normal login and MFA checks. Cybersecurity News previously covered this GlobalProtect authentication bypass.
After establishing access, attackers use remote monitoring and management tools to explore internal networks. They move between systems through Remote Desktop Protocol and Server Message Block, then prepare tools for credential harvesting, data theft, and ransomware deployment.
The most notable case involved a move from the compromised VPN gateway to VMware’s vCenter management appliance. Attackers then disabled the execInstalledOnly security control on ESXi hosts and used a custom tool to extract credentials offline from a domain controller’s VMDK virtual disk. Unit 42 did not name the tool or provide its implementation details.
Reading credentials directly from the disk bypasses endpoint detection and response controls inside the affected virtual machine. The approach targets the infrastructure beneath the operating system rather than relying on a credential-stealing program running within it. Cybersecurity News has also reported on VMware attacks involving detached domain controller disks.
Unit 42 also observed attackers combining this initial access with tools targeting Veeam backup infrastructure through CVE-2023-27532. That separate flaw can expose encrypted credentials stored in the backup configuration database, potentially opening access to backup hosts.
Defenders should examine GlobalProtect logs for successful gateway-connected events linked to suspicious sources and client details. Reported indicators include 104.207.144[.]154, 146.19.216[.]125, device names GP-CLIENT and DESKTOP-GP01, and host IDs aa:bb:cc:dd:ee:ff and 00:11:22:33:44:55. Earlier monitoring found that many probes did not establish full VPN sessions, making connection events important for investigation.
Organizations should follow the Palo Alto Networks advisory and upgrade every affected portal and gateway. Temporary mitigations include disabling authentication override or generating a new certificate dedicated exclusively to override cookies.
Hackers are exploiting flaws in Plex Media Server to install cryptocurrency mining malware, with a researcher recording successful attacks against a honeypot on October 17, 2026.
The activity follows the release of Plex2Shell, a public exploit that chains four vulnerabilities to run code without logging in. Later observations also revealed proxy software running alongside the miner.
The findings from Boredhackerblog show active exploitation of an exposed test server, rather than scanning alone. However, the available evidence does not establish how many real servers have been compromised or identify the attackers behind the activity. The researcher also warned that restrictions on outbound traffic initially prevented collection of some payloads.
How the Plex2Shell Exploit Works
Plex announced security updates on September 1, urging users to install Plex Media Server 1.43.3 and Plex Desktop 1.115.0. Its official security notice warned that NAS users might need to install updates manually. Cyber Security News previously covered the Plex security update and affected releases.
The exploit combines CVE-2026-96652, CVE-2026-96654, CVE-2026-96655, and CVE-2026-96656. According to the Plex2Shell repository, the chain starts with server-side request forgery, which tricks Plex into sending requests chosen by an attacker. It then reaches internal functions, gains access to owner-authorized requests, and writes a file to an attacker-selected location.
The final stage abuses the loading of an unsigned codec to execute code. The repository identifies versions before 1.43.3.10828 as vulnerable and lists 1.43.3.10861 as fixed. Although the exploit supports Linux and Windows targets, the reported honeypot activity involved a Linux-based Plex deployment running in Docker.
Honeypot Captures Miner and Proxy Activity
In the researcher’s report, the first exploitation attempt came from 45.194.92[.]222. Further attempts involved 91.92.40[.]202 and 176.65.139[.]228. Recorded requests targeted /player/timeline/subscribe and included references to internal Plex services, an sslip.io hostname, and the Python-urllib/3.10 user agent.
After outbound access was enabled, the researcher observed downloads from 217.60.194[.]116 involving files named docker and x. Published artifacts included packed and unpacked samples, followed by an XMRig miner. Similar misuse of XMRig has appeared in other campaigns, including attacks against exposed Redis servers.
An update also reported a process named myawesomeproxy and traffic involving proxystream[.]st. The program displayed a message about external use of the device’s internet traffic. These observations raise concerns about proxy abuse, but they do not establish who operates this Plex campaign or prove a connection to a specific botnet.
Administrators should install the latest Plex release and verify the running version, particularly on NAS systems and Docker deployments. On Linux, review the Plex process tree for unexpected child processes, suspicious downloads, and unfamiliar mining or proxy programs. The researcher recommends examining processes with ps axjf.
Defenders can use the published packet captures to develop detections. Files marked “lab” come from controlled tests, not live attacks. The repository also warns that attackers can change ports, domains, and filenames, so matching only fixed indicators will leave detection gaps.
A proof-of-concept exploit that gains root access on OpenBSD by chaining two kernel flaws. The main bug dates back about 37 years to the original BSD source code.
According to Security researchers at Calif, the flaw survived because a shared memory attachment counter named shm_nattch used a signed 16-bit value.
OpenBSD fixed both issues before Calif published the exploit on October 16, 2026. The published research covers a local privilege escalation exploit and does not report active use in real-world attacks.
37-Year-Old OpenBSD Flaw
The first flaw affects System V shared memory handling. By repeatedly forking processes with shared memory records, a local user can push the counter beyond its maximum value of 32,767.
The number then wraps to a negative value. This integer overflow can cause a race condition that leads to a kernel use-after-free. A second flaw provides a conditional out-of-bounds write, giving the researchers enough control to turn memory corruption into root access.
Calif’s exploit maps 127 shared memory segments, removes their mappings, and forks 259 processes to force the counter to wrap. It then shapes kernel heap memory and watches allocator data through sysctl(KERN_MALLOCSTATS).
One process marks a shared memory object for removal with IPC_RMID, while a helper process tries to attach a new segment at the right time. Winning this race creates a size-confused kernel allocation.
The researchers next place IP socket objects near the freed memory and use IP_MULTICAST_TTL to create a lasting struct ip_moptions object. The out-of-bounds write changes two membership counters in this structure.
Closing the socket starts atomic counter changes that alter OpenBSD’s self-referencing page-table mapping. This makes the user-space mapping available to supervisor mode and lets the exploit overwrite a predictable kernel pointer.
The exploit then runs code in the kernel, repairs the changed pointer and opens a root shell. The chain worked with OpenBSD protections such as KARL, SMAP and SMEP enabled, without needing a separate information leak. KARL changes kernel code and data addresses at boot. However, Calif found that parts of the kernel memory allocator remain predictable on the same hardware. Early boot objects can land at stable locations, letting the exploit target the lo0 and enc0 ioctl handler pointers.
OpenBSD addressed the integer overflow in Errata 018 and the reference-counting use-after-free in Errata 026. The OpenBSD 7.9 errata page lists both fixes for all architectures. Binary updates are available through syspatch for amd64, i386 and arm64 systems. Administrators should apply every available patch and reboot so the corrected kernel becomes active.
Calif also proposed wider protection, including safe unlink checks for linked lists, random placement of the page-table map and less predictable kernel allocations. Compiler features such as array bounds checks and allocation isolation could make similar memory bugs harder to exploit.
The PoC source code is publicly available. Calif’s repository identifies the work as part of its MAD Bugs security research project.
Entrar
(@dok2001) 
