Twenty-two pending curl vulnerabilities https://lobste.rs/s/lu8hl9 #release #security
https://daniel.haxx.se/blog/2026/10/07/twenty-two-pending-curl-vulnerabilities/
#security
1744 posts · Last used 1h
Chrome's Response to Recent ccTLD Registry Hijacks https://lobste.rs/s/4fop73 #security
https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/
Whatever went on around the permitter of RAF Farirford it has spooked the USAF, who this weekend 'moved' their heavy B-1 Lancer bombers elsewhere....
Depending on your perspective this could be a panic response to a miss-reported criminal incident, an accusation the UK cannot provide security for airfields, or a bit of political theatre designed to hide something else (although what might be being hidden is not clear).
#RAFFairford #politics #securityhttps://www.bbc.co.uk/news/articles/ck87z09xe82qo
Two arm64-specific miscompiles induce vulnerabilities in curl https://lobste.rs/s/fu57cb #compilers #security
https://mastodon.social/@bagder/117392573268225646
How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers https://lobste.rs/s/gm2ziy #security
https://blog.cloudflare.com/containers-cross-tenant-vulnerability/
From: anyone@icloud.com - Spoofing Arbitrary Apple iCloud Identities https://lobste.rs/s/jpwrmk #security
https://sec-consult.com/blog/detail/from-anyoneicloudcom-spoofing-arbitrary-apple-icloud-identities/
Boosted by @fedicat@pc.cafe
Fedify security updates: 2.0.30, 2.1.26, 2.2.15, 2.3.10, and 2.4.0
Two vulnerabilities have been fixed: GHSA-97w4-f4rq-mgqm, unbounded alternate-document fetch chains vulnerability and GHSA-39gj-rchc-q5m3, unverified activity routed after dereference verification vulnerability.
The patched releases are 2.0.30, 2.1.26, 2.2.15, 2.3.10, and 2.4.0. Both vulnerabilities affect the preceding releases on those lines: 2.0.28 and 2.0.29, 2.1.24 and 2.1.25, 2.2.13 and 2.2.14, 2.3.8 and 2.3.9. If you still use Fedify 1.x, change your dependency to patched 2.x release because package-manager update commands do not cross the declared major-version range.
Unbounded alternate-document fetch chains (GHSA-97w4-f4rq-mgqm, high, CVSS 7.5)
GHSA-97w4-f4rq-mgqm affects Fedify's document loaders when fetching remote keys and ActivityPub documents. Fedify follows alternate-document links supplied through HTTP Link headers and HTML, but following an alternate document reset the redirect counter and visited-URL history. An attacker could therefore make two URLs refer to each other as alternate documents and cause Fedify to fetch them indefinitely. Following an alternate link also dropped the caller's cancellation signal, so aborting the original operation did not stop the fetch chain.
An unauthenticated inbox request could exploit this by referencing an attacker-controlled signing-key URL. Resolving the key could then enter an unbounded alternate-document chain, continuously issuing HTTP requests and DNS lookups and eventually exhausting server resources. Both getDocumentLoader() and getAuthenticatedDocumentLoader() were affected, including their use in @fedify/vocab-runtime and @fedify/fedify.
The fix makes alternate-document links and ordinary HTTP redirects share the same 20-hop limit and visited-URL history. It also preserves the caller's cancellation signal throughout the entire fetch chain. This closes a gap left by the earlier redirect-loop fix for CVE-2026-34148.
Unverified activity routed after dereference verification (GHSA-39gj-rchc-q5m3, medium, CVSS 6.5)
GHSA-39gj-rchc-q5m3 has been present since Context.routeActivity() was introduced in Fedify 1.3.0. Context.routeActivity() verifies an activity before passing it to inbox listeners. When an activity has no verifiable Object Integrity Proof, Fedify dereferences its id and verifies the fetched copy. However, only the Activity object was replaced with the verified copy; the original, unverified JSON-LD document supplied by the caller was retained.
With an inbox queue configured, that unverified document was enqueued and later delivered to inbox listeners without being verified again. An attacker who knew the ID of any dereferenceable activity could therefore submit a document with the same ID but an actor, object, and addressing of their choice, causing the application to process attacker-controlled data as authenticated. Without a queue, listeners received the verified Activity object, but their InboxContext still contained the unverified document, which InboxContext.forwardActivity() could forward to other servers.
Applications that never call Context.routeActivity() are not affected. Activities successfully authenticated using an Object Integrity Proof are also unaffected, as is the HTTP inbox, which does not use this routing path.
The fix replaces both the Activity object and its JSON-LD document with the verified copy when Context.routeActivity() falls back to dereferencing. Inbox queues, InboxContext, and forwarding therefore all operate on the same document that was actually authenticated.
Updating
Update @fedify/fedify:
npm update @fedify/fedify
yarn upgrade @fedify/fedify
pnpm update @fedify/fedify
bun update @fedify/fedify
deno update @fedify/fedify
Check if your resolved dependency versions are at least 2.0.30, 2.1.26, 2.2.15, 2.3.10, or 2.4.0 on the corresponding release line. Please redeploy every Fedify-based servers, after updating.
The full Github Security Advisories are GHSA-97w4-f4rq-mgqmand GHSA-39gj-rchc-q5m3.
Thanks to @adelzaitri for reporting unverified activity is routed after dereference verification issue.
Ask below if anything is unclear.
Greg Kroah-Hartman - Security in the LLM Age https://lobste.rs/s/rghh9w #video #security #vibecoding
https://www.youtube.com/watch?v=NnV_cWeoo5Q
Kernel Recipes 2026 - Security in the LLM age
I got targeted: Trying to get your credentials via a git post-checkout hook https://lobste.rs/s/cd5gdk #security #vcs
https://frankwiles.com/posts/i-got-targeted/
Updates to Full Disk Access in macOS https://lobste.rs/s/9ipypq #mac #security
https://developer.apple.com/news/?id=p6zjojqw
Boosted by @welcome@friends.deko.cloud
Hello Mastodon! I'm into Computer #Security, #Programming, #ReverseEngineering, #Hacking, #Linux, #AmateurRadio, #Privacy, #OpenSource, #Cryptography and generally anything creative and interesting involving tech. Especially things that help people communicate and use computers more privately and securely. Lately I've been tinkering with mesh networks like #Meshtastic, #MeshCore and #Reticulum. Longtime #QubesOS and #GrapheneOS user.
I also enjoy touching grass like #Camping, #Backpacking and generally being in nature. Would recommend.
This is a personal/professional account so keep an eye out for various writeups and research, for work and for fun. Previous jobs ranged from #SoftwareEngineering to Computer Security #Research and #InfoSec, and I'm looking for more of the same.
#Introduction
🖲️ #Cybersecurity #Ciberseguridad #Ciberseguranca #Security #Seguridad #Seguranca #News #Noticia #Noticias #Tecnologia #Technology
⚫ Carbonato Botnet Puts an AI Agent on Hacked Docker Hosts
🔗 https://www.darkreading.com/identity-access-management-security/carbonato-botnet-ai-agent-hacked-docker-hosts
The botnet uses the open source Hermes Agent AI framework to execute commands via Telegram and steal AI API keys from exposed Docker hosts.
CVE-2026-86950: The Great Glyph Grift - An in-the-wild iOS bug with a possible WhatsApp zero-click path https://lobste.rs/s/yfttkn #security
https://calif.io/research/the-great-glyph-grift
Is sandboxing sufficient to contain rogue agents? https://lobste.rs/s/zcr7in #ai #security
https://blog.cryptographyengineering.com/2026/09/30/is-sandboxing-sufficient-to-contain-rogue-agents/















