Check Point uncovered a ChatGPT Lockdown Mode bypass in HTML previews, enabling zero-click data exfiltration and phishing before OpenAI deployed a patch.
Hackers are targeting outdated iPhones and Android phones through infected websites to steal passwords and sensitive data. Here's how to protect your device.
Google's November security update fixes a critical Android vulnerability that can interrupt cellular calls through a hidden message. Here's how to check your device.
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.
Citrix has released security updates for XenServer versions 8.4 and 9 to address a critical vulnerability. This flaw could allow an unauthenticated attacker on the management network to compromise virtualization hosts. The Cloud Software Group published a bulletin (CTX697256) on November 3, 2026, classifying the issue as Critical. The bulletin covers nine CVEs. Citrix XenServer […]
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.
Google released its November 2026 Android Security Bulletin, which addresses critical vulnerabilities that could allow remote code execution without user interaction or additional execution privileges. Published on November 2, the bulletin highlights a framework vulnerability as the most severe issue and also documents other critical remote code execution flaws in Android’s system components. According to […]
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has included a WordPress Core vulnerability in its Known Exploited Vulnerabilities catalog due to evidence of active exploitation. This vulnerability, identified as CVE-2026-119977, allows unauthenticated attackers to execute server-side code during a specific software upgrade window. CISA added this vulnerability to the catalog on November 3, 2026, […]
Cloudflare launched Zero Wire, a public vulnerability intelligence hub that helps security teams investigate critical internet threats, assess exploitation evidence, and prioritize remediation efforts. Available through Cloudflare Radar, the service combines technical research, vendor guidance, and network observations into concise briefings. Cloudflare’s launch announcement positions the platform as a practical starting point for organizations facing […]
You run security at your organization. It’s 7:00 am, and you’re having breakfast. You receive a ping: a new critical vulnerability has been disclosed. Your team scrambles to compare vendor advisories, read technical research, check which systems run the affected software, and answer familiar questions from the business: are we affected, and what are we doing about it? Another disclosure arrives before that work is finished.
AI is changing both the volume and speed of critical vulnerability discovery. It can analyze large codebases at scale and surface deeply nested flaws that may have existed for years without being found through human review. That discovery momentum will put more pressure on security teams to understand the impact of each disclosure on their infrastructure.
To help security teams prepare, today we’re introducing Zero Wire: a public vulnerability intelligence feed on Cloudflare Radar, bringing the clarity of a news wire service to critical security developments. It helps security leaders and practitioners understand significant vulnerabilities and decide what to do next.
How it works
Zero Wire lives inside Cloudflare Radar under the security section.
Each briefing brings together a plain-language explanation of the vulnerability, who should investigate it, recommended actions, and links to the evidence and vendor guidance. The format is deliberately simple: an index card with what you need to know, without the drama. A CISO should be able to understand the issue quickly and ask the right questions. An engineer should be able to follow the same briefing to the technical guidance needed to investigate and remediate it.
We also offer a pre-compiled prompt you can use with your agent to assess the impact on your infrastructure. Cloudflare contributes security research, observations from our network, and practical knowledge of the controls that can help reduce exposure. The information is useful whether or not you are a Cloudflare customer.
Zero Wire brings that context together with authoritative external sources, giving readers a starting point for assessment and a place to return as an issue develops.
Our focus
Rather than a catalog of every CVE, Zero Wire complements vendor advisories and vulnerability databases, linking readers to the evidence and technical guidance needed to act. Zero Wire focuses on critical CVEs in Internet-facing software, such as vulnerabilities in web applications, the runtimes and libraries they depend on, and services exposed to the Internet, where a proxy can help mitigate exploitation.
We select significant issues that security teams need to understand and assess. Each briefing explains the potential impact, which deployments should be investigated, what is known about exploitation, and the available mitigation and patching guidance. A vulnerability’s severity and evidence of active exploitation are distinct: readers need both to make informed decisions.
A dedicated Cloudflare protection, such as Web Application Firewall (WAF) rules, is not a prerequisite for inclusion. Some issues require vendor updates or changes beyond the traffic Cloudflare can inspect. Where Cloudflare controls can help, we explain their scope and configuration requirements.
A walk through Zero Wire
Start on the Zero Wire homepage. Each card introduces an issue, identifies associated CVEs where applicable, and summarizes why it matters and what to do. You can search for a published briefing using a CVE or issue name, and follow technology tags to related entries. One briefing can cover several related CVEs when understanding them together makes the response clearer.
Find what needs attention
The homepage separates briefings into two categories. “Needs attention” brings together issues requiring active assessment or action, including those with known exploitation or developing guidance. “Reference” keeps briefings available when guidance has stabilized. Moving to “Reference” does not mean every affected system has been patched: an older vulnerability can still matter to an organization that has not completed remediation.
The status and last-checked date help you interpret each card. Known exploitation, an ongoing investigation, and an available vendor fix describe different things. Read them alongside the briefing’s evidence rather than treating them as a verdict on your own environment.
Understand what happened and who should investigate
When you open a briefing, the overview tells you what happened, why it deserves attention, and which teams should investigate. The explanation connects the technical issue to its practical consequences, such as service disruption or risk of data exposure.
For example, the recent php2shell vulnerability concerns flaws in the PHP runtime. That distinction matters for teams running applications such as WordPress or Magento: updating application code or a plugin alone does not repair the underlying runtime. The briefing helps readers identify the right system owners and directs them to the PHP security guidance for affected versions and remediation.
Turn the briefing into an action plan
What to do now gives your team a short set of next steps. Depending on the issue, that can mean identifying affected deployments, checking versions with a hosting provider, applying vendor updates, reviewing suspicious activity, or keeping compensating controls in place while patching.
The purpose is to make the next conversation concrete. For a PHP deployment, ask which runtime is actually running, whether the vendor’s fix has been applied, and who owns the update. Follow the linked vendor advisory for detailed applicability and remediation instructions, which can change as the investigation develops.
Assess your exposure with an AI agent
In this section, we share a prompt that can be used with your AI agent to quickly assess the impact on your infrastructure. The prompt asks for a read-only assessment of deployed software, relevant vendor fixes, exposure, and compensating controls, with per-asset evidence, unknowns, and next actions. It helps your team investigate its own environment; copying the prompt does not itself scan or change systems.
Check the evidence and follow what changed
To help you learn more about the vulnerability, each briefing links to external documents such as CVE records, research, and relevant exploitation evidence, including CISA’s Known Exploited Vulnerabilities Catalog. These sources answer different questions. A vendor advisory establishes affected versions and remediation guidance. An exploitation report provides evidence of attacker activity.
If applicable to a briefing, Cloudflare can add context about traffic seen on our network, for example by showing traffic matching WAF rules that indicates exploitation attempts. Those distinctions matter. Observing an attack attempt does not establish that a particular organization was compromised. Equally, a lack of observed attempts on Cloudflare’s network does not establish that exploitation is absent elsewhere. Briefings distinguish what the sources establish from what remains unknown.
Where available, charts add context to that evidence. The php2shell briefing shows the volume of HTTP requests matching Cloudflare WAF managed rules over time. Note that requests matching these rules are not a count of compromised systems or successful exploits; the chart aims at providing practitioners a sense of what the focus level is by threat actors on a particular vulnerability.
Finally, update chronology records important developments, such as new advisories or changes to the evidence and response guidance. Together with the last-checked date, it helps returning readers understand what has changed since their previous visit.
Understand Cloudflare’s role
The Cloudflare section provides links to whether we offer compensating controls or provide a way to mitigate the vulnerability impact on your infrastructure.
If a particular CVE can be addressed with a WAF rule, the briefing reports its availability and essential configuration requirements. When applicable, paid Plans and free Plans links take customers to the relevant dashboard configuration. The next step is explicit: “Review your WAF configuration to determine whether you are protected”. A link allows you to review your security posture, it does not automatically enable a rule or verify a deployment.
Note that a WAF mitigation is a compensating control for the traffic it covers, it is not a replacement for fixing vulnerable software. Blocking the requests can prevent exposed data from reaching an attacker, but it cannot undo actions already performed at the origin. The security teams should always follow the vendor remediation guidance.
Stay informed with Zero Wire
A useful vulnerability briefing should leave you with a clearer understanding of the issue and a concrete next step. Day Zero brings those essentials together: what happened, who should investigate, what to do now, and where to find the evidence.
Visit Zero Wire vulnerability intelligence, share the relevant briefings with the teams responsible for your systems, and return for new entries and updates. When the next disclosure arrives, we want you to spend less time assembling the basic facts and more time acting on them.
Microsoft’s analysis of approximately 383,000 disclosed vulnerabilities shows that attackers overwhelmingly favor weaknesses enabling system takeover rather than exploiting vulnerabilities indiscriminately. The research identifies 2,056 CVEs linked to real-world exploitation, roughly 0.5% of the population, highlighting why vulnerability management must prioritize demonstrated attacker utility over disclosure volume or severity scores alone. Covering vulnerabilities published from […]
Apache Wicket vulnerabilities: a security update fixes 19 flaws, including CVE-2026-84170 upload DoS and XSS bugs. Upgrade to 8.20.0, 9.25.0 or 10.12.0.
On October 19, 2026, we learned about eMudhra’s eight shockingly weak keys: where eMudhra was trusted to pick a 115-digit number for their virtual combination lock protecting the Internet, they picked the number 4. Not even four digits, just the number 4. The other seven keys were similarly weak: 56, 66, 115, 155, 156, 230 and 237.
The next day, we wrote a blog post on the immediate action we took to mitigate this leak, and what customers needed to do on their end to stay secure. Now, we are sharing a more in-depth follow up on the evidence we’ve seen of exploitation, and the progress seen on visitors patching their systems.
Let's start with the scale of the problem. A certificate authority (CA) with weak keys this serious is unprecedented, and the potential consequences are significant. While there have been plenty of compromised certification authorities in the past (such as DigiNotar, TÜRKTRUST, and TrustWave), access to their keys has always been contained to a degree; these incidents gave a limited set of attackers or organizations the ability to issue fraudulent certificates. The eMudhra incident is fundamentally different; the affected intermediate private keys could be recovered almost instantly by anyone from the public certificates themselves. Anyone can independently recover these same signing keys and create certificates for any domain that an unpatched client not enforcing Certificate Transparency would accept.
eMudhra announced they’re exiting the public CA business and have claimed a mistake in a key generation script, but have not yet shared the script. They signed a certificate revocation list (CRL) with what might’ve been a correctly generated key, and subsequently corrected it to be signed with the weak key.
How did that come to be and why didn’t that set off alarms? Much has to be cleared up, including the role of the auditors and cross signers. This blog proposes the fixes and next steps for organizations to ensure they are secure.
Patching Cloudflare
Our primary concern remains the security impact on Cloudflare, our customers, and the Internet as a whole. At the time of writing, all high priority Cloudflare systems have been patched. A small number of confirmed low impact tickets are being worked on.
We started patching high-impact systems immediately on October 19. These included customer origin-facing proxies using Pingora, responsible for most of our outbound connections. These were patched in hours to reject the vulnerable eMudhra keys. At the same time, we started an AI-assisted analysis of our source code to find all other systems that trust these weak keys. Within four hours we had a full analysis. We assigned a ticket with preliminary analysis for each system, and asked the team to confirm and/or adjust the analysis before the end of the day. Where high impact was identified, we asked to patch immediately, and for the lower impact, remediation was due at the end of last week.
Has Cloudflare seen exploitation across its network?
To track whenever a customer’s server (or attacker) presents a certificate signed by eMudhra’s weak keys, we added logging to Pingora. As this outbound service accounts for the vast majority of outgoing TLS connections from a Cloudflare machine, any attacker attempting to snoop using the eMudhra keys would trigger this logging. The logging finished rolling out October 21.
At the time of writing, a week later, we’ve seen about 22,000 attempted handshakes with the weak eMudhra keys. Two-thirds of the attempts were fetches of test sites such as emudhra.we-have-a-problem.com (which we mentioned in the developer guidance in our earlier post). Almost all of the remaining third went to origins who appeared to set up a certificate for themselves using the weak intermediate. Every handshake configured to verify the certificate was refused, as we already patched.
About 160 of these handshakes stood out: the certificates’ Subject Alternative Names (SANs) were naming other organizations’ domains, unrelated to the Server Name Indication (SNI) requested in the handshake. Some of those names were domains related to consumer IoT devices. We noticed as well that those forged certificates were made after the keys leaked and some were valid for over two years, longer than any public CA may issue. However, these certificates looked like the servers' own default certificates rather than part of an attempt to intercept our connections. They named domains other than the ones being connected to, so they would have failed hostname verification anyway. And in several cases, a server presented the same certificate to connections from many of our locations, which means it came from the server itself rather than from something on a single network path.
Thus while there is no evidence of the weak keys being used to intercept Cloudflare's connections so far, these keys appear to have been used to forge certificates within hours of the weakness becoming public: one of the forged certificates we saw was dated October 20 at 18:19 UTC, less than an hour after Mozilla's bug report was made public. This does not exclude carefully targeted interception. For that we have to rely on the usual indirect signals of system compromise — and so far, we have not seen any such signals.
How many visitors are still vulnerable?
So much about patching Cloudflare, but what about our visitors? We cannot directly test whether a visitor still trusts the weak keys without breaking connections, so we have to do something more indirect. For that we used our challenge pages:
We rolled out an update to send out two probe connections on a fraction of challenge pages: one probe to ca1.cloudflarecaptcha.com and one to ca2.cloudflarecaptcha.com. Initially we installed an eMudhra signed certificate on ca1.cloudflarecaptcha.com and a regularly signed certificate on ca2.cloudflarecaptcha.com as control. Then we record whether these probes succeeded. This allows us to see if visitors that are served a challenge page still trust the weak eMudhra keys.
What did we find? With 50 million probes over the last week, we see this:
Big caveat upfront: by design the traffic to these challenge pages is highly skewed. There are many (unconfirmed) bots in there. Also, only clients that execute JavaScript (like browsers) will send probes.
The jump in the data is due to the following changes—all times are UTC:
October 23 15:30, we changed our control endpoint to also serve an eMudhra certificate, but this time without signed certificate timestamps (SCTs). There were some differences in acceptance, but not large. We could’ve added a new endpoint, but that would’ve required a slow release of our challenge platform. Changing the endpoint was easier.
October 23 16:30, our challenge platform rolled back to a previous version because of an unrelated issue. The probes returned October 27 at 10:00.
October 27 16:37, we noticed we did not send the G3 cross-sign, which not all clients knew about, and added it to both endpoints. We removed SCTs from both.
October 27 16:49, we switched ca2 to chain up to the AAA Certificate Services root.
October 27 18:18, we ramped up probes to be included from 1% to 10% of all challenge pages served on non-paying customer zones.
With those caveats out of the way: what do we notice? Up-to-date modern browsers are mostly patched, but bots and old browsers are not. Also embedded browsers, like Android WebView, lag behind patching with 30–40% still accepting. Over the first weekend (with the monitoring gap), we see clear evidence of patching, but afterwards we see little movement.
On October 29 around 18:00 UTC, we released a detection that caught a large influx of bot traffic identifying as Chrome 150-154 on macOS. This can look like patching in the top graph, but it is actually a change in traffic classification: the same user agents show a corresponding increase in acceptance among traffic with bot signals detected in the bottom graph.
Chrome 150-154 on Linux is the notable exception: its acceptance continues to decline, consistent with further patching in that cohort. Given the bot-heavy and changing traffic mix, that evidence is suggestive rather than conclusive. Otherwise, we still see little movement.
Breaking down by network (ASN) we see:
Across the large networks, more than half of probes still accept the compromised chain, both among traffic with no bot signals detected (top graph) and traffic with bot signals detected (bottom graph). Over the weekend we saw some patching, but afterwards the trend has been flat.
The big caveat still holds: traffic is skewed by (unconfirmed) bots. But bots are also just software that need security updates. And if they’re in any way representative of overall software updates, then the picture is quite dire indeed.
What can you do?
Patch! Dennis Jackson has a great crowdsourced website with instructions. Especially if you’re a developer on macOS, you want to follow these instructions. If you’re a Cloudflare customer, check out last week’s blog post on what needs to be done on your end when using certain products like WARP or Tunnel.
Looking ahead
At Cloudflare, we have a quick-revocation mechanism in place in some products. To bring it to more systems at Cloudflare and industry, we’re excited about projects like upki that understand a trust store can’t be a static list of root certificate authorities, but needs the ability to be quickly updated with information like revocation and certificate transparency keys. As vulnerabilities are discovered at a faster pace than ever, it is vital that they can be addressed quickly and effectively.
Hackers exploited a chain of zero-day vulnerabilities in Ivanti Connect Secure (ICS) VPN appliances, allowing them to execute commands with root access, steal credentials, and probe internal networks. Volexity has identified the unknown attacker as UTA0576 and traced the exploitation back to October 3, 2026, targeting an appliance that was fully patched at the time. […]
Entrar
