Veeam warned that a critical Linux kernel flaw with a CVSS score of 9.8, could cause denial of service or memory corruption across backup and recovery products.

Veeam’s November 6 impact statement identified a Linux kernel use-after-free vulnerability (CVE-2026-98432) in TCP/IPv4 connection setup and outlined update paths for affected systems.

Its security advisory does not report active exploitation or confirm remote code execution. The stated risks could interrupt backup and restore work if an affected appliance becomes unavailable.

Affected products include Veeam Software Appliance 13.1 and Veeam Infrastructure Appliance 13.1. Infrastructure roles include backup proxies, hardened repositories, mount servers, gateways, and Cloud Connect components. Workers deployed through Veeam hypervisor plug-ins also need the updated kernel.

Veeam Warns Critical Linux Kernel Flaw

Windows-based Veeam Backup & Replication installations also require attention because they deploy Linux helper appliances. These support file recovery, virtual labs, and cloud restores. The advisory lists affected helper appliances in versions 13.1 and 12.3, rather than identifying the Windows kernel as vulnerable.

The disclosure follows separate Veeam authorization bypass fixes and earlier Backup & Replication security updates. Those issues have different causes and patch requirements, so administrators should not assume earlier product updates resolve this kernel flaw.

Veeam says a patched kernel has been available for Software Appliance and Infrastructure Appliance 13.1 since November 2. The fixed package is 5.14.0-570.60.1+27.2.el9_6_ciq, delivered through Veeam Updater.

Administrators can install available updates from the Veeam Host Management console without waiting for the automatic schedule. A restart may be required.

The updater checks repositories every 12 hours. Under default settings, mandatory updates install on the nearest Sunday at 14:00 in the backup server’s time zone.

Teams should check update history to confirm installation. Systems using a local repository mirror receive the package only after that mirror synchronizes.

For Windows deployments, the 13.1 private fix requires Backup & Replication 13.1.2.57. Repacked 13.1.2 installation media includes the fix.

Veeam’s November 6 advisory says the private fix for version 12.3 will become available soon. Temporary helper appliances receive updated images when deployed again.

At the same time, persistent virtual labs and Microsoft Azure helper appliances must be redeployed. Replace recovery media created before the update. Hypervisor plug-in workers receive the updated kernel on their next launch.

AWS, Azure, and Google Cloud plug-in appliances receive Ubuntu kernel updates through Veeam Updater. Administrators should install available updates and review the Ubuntu CVE tracker for package status.

Veeam Kasten container images do not include a kernel, but their Kubernetes nodes still need vendor checks. Customer-managed Linux proxies, repositories, and gateways also require distribution updates. Completing these separate checks helps teams avoid leaving recovery components unpatched after updating the main appliance itself.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Veeam Warns Critical 9.8 Linux Kernel Flaw Could Crash Backup Appliances and Disrupt Recovery Operations appeared first on Cyber Security News.

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.

Earlier SonicWall SSLVPN authentication bypass coverage shows why remote access flaws deserve attention. However, that reporting concerns CVE-2024-53704, a separate vulnerability.

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.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post SonicWall Warns of Potential In-the-Wild Exploitation of SSLVPN Flaw That Bypasses MFA appeared first on Cyber Security News.

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.

Indicators of Compromise

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Hackers Launch 240,000 Attempts to Exploit a WordPress Core Flaw That Allows Remote Code Execution appeared first on Cyber Security News.

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.

ChatGPT Lockdown Mode Bypass

This is not the first hidden exit path Check Point has found. In March, the team showed that DNS tunneling in ChatGPT’s code runtime could send chat data to an outside server. We covered that bug in ChatGPT Vulnerability Let Attackers Silently Exfiltrate User Prompts. The new flaw shows how closing one path does not protect the others.

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.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Hackers Could Bypass ChatGPT Lockdown Mode to Steal Conversations Without Users Knowing appeared first on Cyber Security News.

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.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Microsoft Paint 0-Click Vulnerability Could Allow Hackers to Take Control of Windows PCs appeared first on Cyber Security News.

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.

The same actor also broke into WordPress sites, as our story on hackers exploiting WordPress flaws to steal government records shows. GreyNoise counted more than 18,000 stolen records in one case.

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.

Indicators of Compromise

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Hackers Exploit Zyxel GS1900 Zero-Day in the Wild to Hijack Network Switches appeared first on Cyber Security News.

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.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Google Patches Over 200 Android Vulnerabilities, Including Critical Zero-Click RCE Flaws appeared first on Cyber Security News.

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.

AI is making cyberattacks faster and cheaper. Are your defenses ready to respond at machine speed?

The post TeamViewer Security Flaw Could Turn Remote Support Sessions Into Computer Takeovers appeared first on Cyber Security News.

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.

AI is making cyberattacks faster and cheaper. Are your defenses ready to respond at machine speed?

The post Palo Alto Confirms Active PHP2Shell Exploitation Targeting Exposed PAN-OS Management Interfaces appeared first on Cyber Security News.

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.

AI is making cyberattacks faster and cheaper. Are your defenses ready to respond at machine speed?

The post Node2Shell Vulnerability Actively Exploited in the Wild, CISA Warns appeared first on Cyber Security News.

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.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post OpenSSL 4.1.0 Released With DTLS 1.3 and Post-Quantum Security Improvements appeared first on Cyber Security News.

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.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Oracle Issues Emergency Java Update for Critical 9.1 HTTPS Trust Vulnerability appeared first on Cyber Security News.

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.

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.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Fortinet Urges Customers to Patch Critical Flaws Affecting FortiOS, FortiManager, and FortiAnalyzer appeared first on Cyber Security News.

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.

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.

For continuing coverage, see Cyber Security News’ report on PHP’s planned emergency security update and its coverage of other recent PHP vulnerabilities.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Cloudflare Detects Early Exploitation Attempts Targeting Two Leaked PHP Vulnerabilities appeared first on Cyber Security News.

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.

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.

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.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post PHP2Shell Vulnerability Gets a Public PoC Exploit for Security Testing appeared first on Cyber Security News.

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.

An EDR alert reveals an attack. But can it tell the full story? Discover how to reconstruct the attack timeline.

The post Hackers Exploit Palo Alto VPN Flaw to Bypass MFA and Steal Credentials From VMware Disks appeared first on Cyber Security News.

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.

An EDR alert reveals an attack. But can it tell the full story? Discover how to reconstruct the attack timeline.

The post Hackers Exploiting Plex Vulnerabilities in the Wild to Deploy Cryptominer Malware appeared first on Cyber Security News.

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.

The case shows how old design choices can remain hidden in trusted operating-system code for decades. Recently, we covered a 27-year-old OpenBSD authentication flaw and an earlier OpenBSD NFS double-free vulnerability.

An EDR alert reveals an attack. But can it tell the full story? Discover how to reconstruct the attack timeline.

The post 37-Year-Old Kernel Flaw Exploited to Gain Root Access on OpenBSD — PoC Released appeared first on Cyber Security News.

Security researchers from the cybersecurity firm Calif demonstrated a working untethered jailbreak for iOS 27.0.1 on Apple’s newest iPhone 18 Pro.

The live demo took place at Hexacon 2026, the offensive security conference organized by Synacktiv in Paris on October 16. It is one of the first public signs that Apple’s latest phone and software can already be fully opened up, only weeks after both reached users.

On stage, the researchers restarted the iPhone 18 Pro. It booted to the Apple logo, reached the lock screen, and was unlocked with the passcode. The jailbreak then came back on its own without the phone being connected to a computer.

This is what “untethered” means. The jailbreak survives a full reboot, which makes it the hardest and rarest kind to build on modern iPhones.

Next, the team connected to the phone over SSH on port 2222 and logged in as root. The id command returned uid=0, which confirms full root access. The uname output showed Darwin Kernel 27.0.0 built on XNU 13432.2.10 for the T8160 chip, with the model listed as iPhone19,2. The sw_vers command confirmed iOS 27.0.1, build 24A446, and neofetch listed 67 packages installed through dpkg with an uptime of only two minutes.

Getting root on a current iPhone usually needs a chain of several bugs. An attacker has to escape the app sandbox, take over the kernel, and get past hardware-backed defenses such as Pointer Authentication Codes (PAC).

Keeping that access after a reboot is even harder because Apple checks the code that runs at startup. The researchers have not shared which flaws they used, and no public tool has been released.

Apple released iOS 27 on September 14 with fixes for more than 120 flaws, including 20 in the kernel, according to its official security notes. It was part of a wider release that fixed 273 vulnerabilities across Apple devices. Earlier this year, Apple also patched an actively exploited iOS zero-day used against targeted individuals.

For most users, the risk is low for now since the method is not public. However, spyware makers often use the same type of bug chain, so iPhone owners should install Apple’s next security update as soon as it arrives.

The post iOS 27.0.1 Untethered Jailbreak Demonstrated on iPhone 18 Pro appeared first on Cyber Security News.

Next.js has released security updates for two critical vulnerabilities that could let remote attackers run malicious code without logging in. A third, high-severity flaw could stop affected applications from serving requests.

The issues involve cached functions, SVG image processing, and Server Actions, with fixes available in Next.js 16.4.1 and 15.5.28. Published on October 14, 2026, the advisories describe separate attack paths with different requirements

Both remote code execution flaws score 9.5, while the denial-of-service issue scores 8.2. Application settings and enabled features determine exposure, so version checks are only one part of risk assessment.

The first vulnerability, tracked as GHSA-673q-mjm6-r5xr, affects App Router applications using Cache Components. An application becomes vulnerable when a use cache function returns multiple typed arrays. Under these conditions, attackers could achieve remote code execution without authentication or user interaction.

Next.js releases 16.0.0–16.4.0 are affected by the flaw, which is fixed in version 16.4.1. Developers should upgrade immediately, as no workaround or CVE identifier is available.

Critical Next.js Vulnerabilities

Earlier React and Next.js RCE reports highlight server-side risks, but the newly disclosed cache flaw has a separate trigger and is unrelated to React2Shell.

The second flaw, CVE-2026-96889, involves a memory-related weakness in an upstream library the Image Optimization API uses to handle SVG files. It can lead to remote code execution on Next.js deployments running on glibc-based Linux. The advisory lists no required privileges or user interaction.

The official image optimization advisory lists affected versions as 10.0.0 through 15.5.27 and versions above 16.0.0 through 16.4.0.

Developers can address this issue by ensuring Next.js uses sharp 0.35.5 or later. Installing the patched Next.js releases ensures package managers provide a fixed dependency.

The third vulnerability, GHSA-p3m5-59mp-jv5r, affects App Router applications with at least one Server Action. Crafted requests can drive excessive CPU usage, preventing the same process from handling further requests. Applications using Pages Router, or those without Server Actions, are not vulnerable.

Affected versions include 13.0.0 through 15.5.27 and 16.0.0 through 16.4.0. There is no workaround besides upgrading. Previous coverage of Next.js security patches highlights related feature-specific risks, but those earlier fixes do not replace this update.

Developers should install Next.js 15.5.28 or 16.4.1 as appropriate. Updating only sharp addresses the image flaw, not the separate cached-function or Server Actions vulnerabilities.

Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs.

The post Critical Next.js Vulnerabilities Allow Hackers to Execute Malicious Code Remotely appeared first on Cyber Security News.