#vulnerability

#hackers have begun exploiting a critical #Brotli #vulnerability known as #Node2Shell, #Broccoli2Shell, and #HTTP2Shell. https://nvd.nist.gov/vuln/detail/cve-2026-111497 #infosec #security #cisa #exploit

Fedify security updates: 2.0.35, 2.1.31, 2.2.20, 2.3.15, and 2.4.5 If you use an affected Fedify release, update now. Two server-side request forgery vulnerabilities have been addressed: GHSA-r48c-xx2h-fv4g, a DNS rebinding bypass of Fedify's private address checks, and GHSA-cj5r-cw77-6gwp, unvalidated page and favicon requests in fedify nodeinfo. Deno deployments need additional network restrictions; upgrading Fedify alone does not close the DNS rebinding vulnerability. The patched releases are 2.0.35, 2.1.31, 2.2.20, 2.3.15, and 2.4.5. Update to the corresponding release on your minor line, with the runtime mitigations described below. The affected releases on these lines are 2.0.34 and earlier, 2.1.30 and earlier, 2.2.19 and earlier, 2.3.14 and earlier, and 2.4.4 and earlier. For ongoing support, the security policy covers the latest two minor lines, 2.3 and 2.4. Users on releases before 2.0 should move to a supported release. DNS rebinding bypasses SSRF protection (GHSA-r48c-xx2h-fv4g, medium, CVSS 5.4) Fedify checked that a hostname resolved only to public addresses, then let fetch() resolve it again when connecting. An attacker controlling the hostname's DNS answers could return a public address for validation and a private or loopback address for the connection, causing requests to reach internal services. Redirects and alternate-document links were subject to the same gap. This affects document loading, including authenticated document loading, outbound activity delivery, NodeInfo lookups, and WebFinger lookups in @fedify/fedify, @fedify/vocab-runtime, and @fedify/webfinger. On Node.js and Bun, the fix makes connections only to addresses that passed validation. Calling validatePublicUrl() before an application's own fetch() still does not pin that connection. Setting allowPrivateAddress: true continues to permit private destinations. On Bun, deployments with HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY set, including their lowercase forms, should upgrade to Bun 1.4.3 or later. Alternatively, unset those variables for the Fedify process or configure the proxy to refuse private destinations. Older Bun versions may send requests through a proxy that resolves the hostname again. On Bun versions before 1.3.11, Fedify now refuses HTTPS requests to non-default ports because those Bun versions cannot verify a pinned connection's certificate against the original hostname. See the Bun deployment guidance. Deno's fetch() cannot pin connections to validated addresses. Use Deno 2.8.1 or later with the documented --deny-net list and a Unix domain socket behind a reverse proxy, plus network-level restrictions for private IPv6 ranges. If that setup is unsuitable, apply equivalent outbound restrictions at the firewall or container network layer. Follow the Deno deployment mitigation. Unvalidated page and favicon requests (GHSA-cj5r-cw77-6gwp, low, CVSS 3.1) An operator running fedify nodeinfo against a malicious instance could cause the CLI to send a GET request to a loopback, link-local, or private address from the operator's machine. The NodeInfo lookup validated destinations, but the subsequent page and favicon requests used plain fetch() with automatic redirects. A malicious favicon URL or page redirect could therefore reach an internal endpoint. The attacker does not directly receive the response body, but the request can affect an internal endpoint with GET side effects. The fix validates page, favicon, and redirect destinations, skipping the favicon when a destination is private while still showing the NodeInfo document. Upgrade @fedify/cli separately from the library. Until then, --no-favicon or --raw avoids these page and favicon requests. The Bun and Deno caveats above also apply to the CLI. Updating Use the command for your package manager to install 2.4.5 explicitly: npm install @fedify/fedify@2.4.5 yarn add @fedify/fedify@2.4.5 pnpm add @fedify/fedify@2.4.5 bun add @fedify/fedify@2.4.5 deno add jsr:@fedify/fedify@2.4.5 If you stay on another minor line, substitute 2.0.35, 2.1.31, 2.2.20, or 2.3.15 as appropriate. Update direct dependencies on @fedify/vocab-runtime and @fedify/webfinger to the same release as well. Check the resolved versions in your lockfile, since an ordinary update command can stay within a vulnerable dependency range or leave a transitive dependency locked. Apply the runtime mitigations above and redeploy all web and worker processes. For an npm-installed global CLI: npm install -g @fedify/cli@2.4.5 For other installation methods, reinstall the corresponding patched version using the CLI installation instructions. Check fedify --version before using it against an untrusted instance. Thanks to @finalchild@twt.rs for reporting the DNS rebinding issue and to Zachariah Mithani for reporting the favicon request issue. If anything is unclear, ask below.

(1/5) Some thoughts on yesterday's #PHP #vulnerability 🔒 Normally, vulnerabilities are patched before we hear about them, with key distributors notified in advance to reduce risk. This time, a security researcher accidentally published details early, and a for-profit PHP distributor broke embargo and leaked the fix. The vulnerability was exploited in the wild within the hour, making everything worse.

Wired: A Device Hidden in Cars Across the US Leaves Them Vulnerable to Hacking and Paralysis. Patch It Now "You can check if your car has the device by looking for a KARR sticker on your car's driver-side window—or in some cases a sticker reading, “SWDS” for SouthWest Dealer Services, a subsidiary of Acrisure Protection Group—as well as a small button with a blinking light attached to the underside of your car's dashboard. ...Car owners in Southern California are most likely to have the device installed due to its popularity among car dealers in the region, but the UCSD researchers warn that they've found the devices installed in vehicles across the US and even in other countries...." https://www.wired.com/story/a-device-hidden-in-cars-across-the-us-leaves-them-vulnerable-to-hacking-and-paralysis-patch-it-now/#intcid=_wired-right-rail_5e32d24e-a7fc-4de8-871f-28936dbf59e9_popular4-2 #vulnerability #automobiles #cars #hacking

BotKit security updates: 0.4.10 and 0.5.7 中文（中国） (Chinese (China)): BotKit 安全更新：0.4.10 与 0.5.7 · 自动翻译 If you use BotKit, update to a patched release now. This update addresses two vulnerabilities: GHSA-4qhx-hhwf-8685, an inbox origin validation flaw that could let an attacker supply forged objects or suppress genuine activities, and GHSA-8863-8468-7hq7, a key ownership validation flaw that could authenticate activities as the wrong actor under specific actor-document configurations. Both flaws originate in Fedify, which BotKit uses for federation. GHSA-4qhx-hhwf-8685 affects incoming activities. Fedify authenticated the activity's actor but did not require the activity's id to share that actor's origin. An attacker needed only an actor and its signing key on a server they controlled, with no account on the receiving server or interaction from the victim. By choosing an activity ID on another server's origin, the attacker could make Create.getObject() and other accessors return embedded objects claiming to live on that server without fetching them from it. BotKit checks that a message's attribution matches the activity's actor, but that does not stop an attacker from attributing an object to themselves while giving it an ID on another server. Its handlers could therefore receive forged objects under that server's object IDs. The same flaw also let an attacker who knew or could predict a genuine activity's ID reserve its idempotency cache entry by sending a forged activity with that ID first. The genuine delivery then received 202 Accepted but did not reach the inbox listeners for one day. With a message queue, this suppression applied across all inboxes on the receiving server. The fix rejects non-portable activities whose IDs have a different origin from their actors before they reach inbox listeners, the queue, or the idempotency cache. The same origin check runs when processing activities from the queue or routing them manually. GHSA-8863-8468-7hq7 affects Fedify's checks that a signing key belongs to an actor. Fedify fetched the actor's document and checked that it listed the key, but did not require the document's id to match the actor ID it requested. An attacker could have activities authenticated as a victim if dereferencing the victim's exact actor ID led to an actor document whose key the attacker controlled. This could happen through a redirect or alternate-document link, including to another origin, or when the victim's server directly served another same-origin actor's document. The attacker cannot normally arrange this condition: it depends on the server hosting the victim's actor ID. A redirect from some other URL on that server is not enough. HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs use the affected ownership checks. The fix requires the fetched actor document's id to exactly match the requested actor ID. Fedify also retains its check that the document's id shares the origin of the final fetched URL. An actor whose ID redirects to a document with a different id can no longer have its keys confirmed through that redirect, even on the same origin and for the same account. Fedify's built-in key cache automatically ignores entries created under the weaker check and fetches and verifies those keys again. If your application separately supplies a custom KeyCache implementation to Fedify, clear it once when upgrading so previously cached false ownership claims are not retained. BotKit 0.4.x versions through 0.4.9 and BotKit 0.5.x versions through 0.5.6 include Fedify versions affected by both vulnerabilities. The first patched releases, and the current recommended releases, are BotKit 0.4.10 and 0.5.7. BotKit 0.4.10 requires Fedify ~2.1.30, and BotKit 0.5.7 requires Fedify ~2.3.14. These are the two supported BotKit lines; users on older lines should move to a supported release. For BotKit 0.5.x, install @fedify/botkit 0.5.7 using the command for your package manager: npm install @fedify/botkit@0.5.7 yarn add @fedify/botkit@0.5.7 pnpm add @fedify/botkit@0.5.7 bun add @fedify/botkit@0.5.7 deno add jsr:@fedify/botkit@0.5.7 For BotKit 0.4.x, install @fedify/botkit 0.4.10: npm install @fedify/botkit@0.4.10 yarn add @fedify/botkit@0.4.10 pnpm add @fedify/botkit@0.4.10 bun add @fedify/botkit@0.4.10 deno add jsr:@fedify/botkit@0.4.10 Check the installed or locked versions: @fedify/botkit should be 0.4.10 or 0.5.7, with @fedify/fedify at least 2.1.30 on the 2.1.x line or 2.3.14 on the 2.3.x line. If you use a routine update command instead, check that your declared dependency range allows the patched release and change it explicitly if needed. After updating, redeploy. The full GitHub Security Advisories are GHSA-4qhx-hhwf-8685 and GHSA-8863-8468-7hq7. See also Fedify's own announcement. Thanks to @2chanhaeng@hackers.pub for reporting the inbox origin validation flaw to the Fedify project. The actor document identity mismatch was found by the Fedify maintainers with AI assistance. If anything is unclear, feel free to ask on GitHub Discussions or Matrix.

Fedify security updates: 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4 If you use an affected Fedify release, update now. Two vulnerabilities have been fixed in @fedify/fedify: GHSA-4qhx-hhwf-8685, an inbox origin validation flaw that could let an attacker supply forged objects or suppress genuine activities, and GHSA-8863-8468-7hq7, a flaw in the key ownership check that could authenticate activities as the wrong actor under specific actor-document configurations. The releases containing both fixes are 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4. We recommend 2.4.4, or 2.3.14 if you are staying on the 2.3 line. Under the security policy, Fedify supports the latest two minor lines, currently 2.4 and 2.3. Backported fixes are also available in the releases listed above for 2.0, 2.1, and 2.2, but users on those older lines should plan to move to a supported line. Users on affected 1.x releases need to change their dependency to a supported 2.x release. Inbox activity origin mismatch (GHSA-4qhx-hhwf-8685, medium, CVSS 6.5) GHSA-4qhx-hhwf-8685 affects applications receiving activities through Fedify's inbox listeners. The inbox authenticated an activity's actor but accepted an activity id on an origin different from the actor's. An attacker needed only an actor and its signing key on a server they controlled, with no account on the receiving server or interaction from the victim. Since version 1.9.0, Fedify's property accessors have trusted embedded objects whose IDs share the activity's origin. By choosing an activity ID on a victim server's origin, an attacker could make Create.getObject() and other accessors return forged objects claiming to live on that server without fetching them from it. Depending on the application's attribution and authorization checks, this could cause it to store or display forged content under another server's object ID. The same missing check also let an attacker reserve a genuine activity's idempotency cache entry by submitting a forged activity with its ID first. The genuine delivery then received 202 Accepted but did not reach the listeners for one day. When a message queue was configured, the suppression applied across all inboxes on the receiving server. This behavior was confirmed in 1.8.15 and subsequent releases before the fixes; releases before 1.8 were not tested. The first fixes shipped in 2.0.33, 2.1.29, 2.2.18, 2.3.13, and 2.4.3. Earlier releases on each of those 2.x lines are affected. Update to the newer releases recommended above to receive both fixes. The inbox now returns 401 Unauthorized for non-portable activities whose IDs have a different origin from their actors, before they reach listeners, the queue, or the idempotency cache. The same origin check applies to queued and manually routed activities. Setting skipSignatureVerification bypasses this protection along with signature verification. Actor document identity mismatch (GHSA-8863-8468-7hq7, medium, CVSS 5.9) GHSA-8863-8468-7hq7 lists the affected version range as <= 2.4.3, with fixes in 2.0.34, 2.1.30, 2.2.19, 2.3.14, and 2.4.4 on their respective release lines. When confirming that a key belongs to an actor, Fedify fetched the actor's document and checked that it listed the key, but did not require the document's id to match the actor ID it requested. An attacker could have activities authenticated as a victim if dereferencing the victim's exact actor ID led to an actor document whose key the attacker controlled. This could happen through a redirect or alternate-document link to the attacker's document, including on another origin, or when the victim's server directly served a different same-origin actor's document. The attacker cannot normally arrange this: it depends on the server hosting the victim's actor ID. A redirect from some other URL on that server is not enough. No account on the receiving Fedify server is required. HTTP Signatures, Linked Data Signatures, and Object Integrity Proofs use the affected ownership checks. The fix requires the fetched actor document's id to exactly match the requested actor ID, in addition to the existing origin check. An actor whose ID redirects to a document with a different id can no longer have its keys confirmed through that redirect, even on the same origin and for the same account. Servers that normalize actor URLs should use the canonical actor ID as their keys' owner or controller and their activities' actor. The built-in KvStore-backed key cache automatically ignores entries created under the weaker check and fetches and verifies those keys again. If you supply a custom KeyCache implementation, clear it once when upgrading. Otherwise, previously cached false ownership claims can remain trusted after the upgrade. Downgrading to an earlier release is not safe. Updating Update @fedify/fedify using the command for your package manager: npm update @fedify/fedify yarn upgrade @fedify/fedify pnpm update @fedify/fedify bun update @fedify/fedify deno update @fedify/fedify Check the installed or locked version: it should be 2.0.34, 2.1.30, 2.2.19, 2.3.14, or 2.4.4 on the corresponding line. Update commands can stay within your declared dependency range. If that range excludes the recommended release, change it explicitly. For example, to move to 2.4.4: npm install @fedify/fedify@2.4.4 yarn add @fedify/fedify@2.4.4 pnpm add @fedify/fedify@2.4.4 bun add @fedify/fedify@2.4.4 deno add jsr:@fedify/fedify@2.4.4 Clear any custom key cache as described above, then redeploy. If you run other Fedify-based servers, update those too. The full GitHub Security Advisories are GHSA-4qhx-hhwf-8685 and GHSA-8863-8468-7hq7. Thanks to @2chanhaeng@hackers.pub for reporting the inbox activity origin mismatch. The actor document identity mismatch was found by the Fedify maintainers with AI assistance. If anything is unclear, ask below.

Asking for a friend here: someone who doesn't work in Security found a vulnerability in a SaaS used by their child's school that allows impersonation. Any recommendations for a complete newbie to disclose safely without minimal risk of being sued? #Vulnerability #VulnerabilityDisclosure #ResponsibleDisclosure #AdviceNeeded

Notepad++'s update servers have been compromised by Chinese hackers and all users had been exposed to malware. The developer estimated the overall compromise period spanned from June through December 2, 2025. Users should update to version 8.9.1 (or superior) immediately. Source: https://notepad-plus-plus.org/news/hijacked-incident-info-update/ #security #vulnerability #windows #text #editor #notepad #foss #freesoftware #software

An Authlib signature bypass vulnerability (CVE-2026-96760, CVE-2026-28802, CVE-2026-27962) lets attackers forge JWS payloads. Update libraries now. #Authlib #CVE202696760 #Cybersecurity #JWS #Vulnerability

Another day, another critical vulnerability in an edge device. We’ve analysed the CVE-2026-88771, one of the many vulnerabilities disclosed by Citrix recently, based on observed exploitation attempts, and set out what we learned and key takeaways. 🔍🔒 If you’re managing Citrix infrastructure, now’s the time to check for compromise! https://www.cert.europa.eu/blog/taking-execute-logging-a-bit-too-literally-cve-2026-88771 #cybersecurity #cve-2026-88771 #vulnerability

Government activity topped our tracking this week with 284 stories, including 33 today. Some call this a coordinated attack on the state. I think that misses the point. https://theperimetersite.com/report/311 #vulnerability #databreach #infosec

CVE-2026-87902: Critical LFI in WordPress Core 🔗 https://cybersecurefox.com/en/cve-2026-87902-critical-lfi-in-wordpress-core #CVE-2026-87902 #WordPress #vulnerability #LFI #RCE

If you're looking at a Citrix NetScaler ADC or Gateway this morning, you probably saw the warning; two zero-days are being used in the wild right now. https://theperimetersite.com/report/310 #vulnerability #infosec

CVE-2026-100551: OpenClaw for iOS (>=2026.7.1, <2026.8.11) has a CRITICAL vuln in Control UI WebViews — TLS pins not enforced. Attackers can steal Gateway creds if they can redirect traffic. Patch to 2026.8.11 ASAP! https://radar.offseq.com/threat/openclaw-for-ios-versions-202671-and-2026811-do-not-enforce-saved-gateway-tls-pins-in-the-control-ui-5ff1fd58a7f58c18 #OffSeq #Vulnerability #iOS #AppSec

Critical Eufy robot vacuum vulnerabilities expose the Omni C20 and X10 Pro to OS command injection. Patch CVE-2026-93289 and CVE-2026-93291 immediately. #Eufy #CVE202693289 #CVE202693291 #IoT #Cybersecurity #Vulnerability

CISA has issued an advisory for CVE-2026-34223 in Siemens Desigo CC: a compromised graphics document can trigger client-side code execution and write arbitrary files. System compromise and potential lateral movement make this relevant to ICS defenders. #CyberSecurity #ICS #Vulnerability

If I don't get any volunteers I'm going to have to wear a hoodie, don a Guy Fawkes mask, and start frantically typing in my basement like the media's version of a hacker. But seriously, if anyone wants me to identify public vulnerabilities in their systems that attackers could exploit, please DM me. No charge and no shenanigans. #WhiteHat #PenTesting #PenTest #Hacking #Vulnerability #vulnerabilities

Reward: You've received the Gavel of Mild Competence. Do not squander it. https://www.bleepingcomputer.com/news/security/hackers-start-exploiting-critical-wordpress-flaw-for-code-execution #WordPress #CyberSecurity #RCE #Vulnerability #CVE202687902 #PatchedOrPerish (3/3)

For 4,5 years anyone could add rogue JavaScript to build log page by submitting a builds.sr.ht job with OSC 8 escape codes. The attacker could submit build jobs on behalf of the victim viewing the build logs, up to even deploying rogue software on the flagship instance. Curious? Read about the whole journey here: https://blog.arusekk.pl/posts/srht-account-takeover/ #cve_2026_92973 #srht #sourcehut #xss #security #osc8 #ansiescape #ci #vulnerability

What's the biggest risk in an organization? It isn't a gap between your firewall and the internet; the real danger is the distance between how an agency wants to be seen and how the procurement office actually buys… https://theperimetersite.com/report/296 #vulnerability #databreach #infosec