标签：#SEC

VS Code 1.123 adds a two-hour delay before auto-updating extensions to newly published versions, creating a revocation window against supply chain attacks. The delay does not apply to trusted publishers like Microsoft, GitHub, and OpenAI. Similar cooldown mechanisms have now spread across pip, RubyGems, npm, pnpm, Yarn, and Bun. By Steef-Jan Wiggers

You think your AI is just helping you write code. In reality, it's built a logging system on your machine that you never knew existed. Every conversation. Every code snippet. Every file path. Every time you asked "what was my password again?" — permanently archived, without your knowledge. How It Started: An Accidental Discovery I was about to sell my old laptop and decided to clean up my data first. I opened Claude Code's config directory — ~/.claude/ — intending to just remove my API key. Then I saw this: history.jsonl 243 KB / 695 lines sessions/ conversation metadata session-env/ environment variables shell-snapshots/ command execution snapshots telemetry/ 63 telemetry files projects/ 19 project directories ├─ interview-prep/ 31 sessions / 20 MB ├─ spring-ai/ 11 sessions / 13 MB └─ ... 17 more I thought I was just writing code. My computer thought it should record everything. What's Inside These Files history.jsonl — Everything You Ever Asked 695 entries. Every single thing I typed into Claude Code. Including: "I forgot my database password — can you check what passwords were configured in the project files?" "How do I view the database password?" Pasted code snippets Every /model , "who are you?", and project path You casually ask about a password once. It's permanently stored. projects/ — Full Conversation Transcripts (43 MB) If you think history.jsonl only storing user input isn't so bad — you haven't seen this yet. Inside ~/.claude/projects/ , every project directory contains .jsonl files. Opening one 2.3 MB session file: Content Count AI responses 590 AI internal thinking blocks 272 Tool calls 101 Tool call results (including file paths) 100 File history snapshots 208 Every conversation. Every AI response. Every internal reasoning step. Every file operation — what was read, what was modified, what was executed — all written to this file. shell-snapshots/ — Traces of Everything You Ran Your system PATH. Installed tools. Java version. All sitting in command s

Cybersecurity firm Chainguard has announced the launch of Athena, an industry coalition to use artificial intelligence to find and fix vulnerabilities in widely-used open-source software before attackers can exploit them. The coalition focuses on libraries, containers and other components that underpin web browsers, data centres, smartphones and payment systems. By Matt Saunders

🗓️ This Week While organizing ideas for my first iOS app , I remembered an old web app idea called ToneDrill , which I had casually built before to help practice note names on a guitar fretboard🎸. I decided to try turning it into an iOS app 🛠️. I clarified the purpose of ToneDrill , its minimum requirements , and its core features , then organized them in Notion 📝. I was curious to see how well Codex could implement an iOS app from those minimum requirements , so I gave it a try right away💡. I reviewed the SwiftUI code generated by Codex and worked through the app logic to understand how it was implemented 🔍. For now, I was able to create a working app, which felt like a meaningful step forward 🚶. I created the top page UI design for my portfolio website in Figma 🎨. I focused on keeping the structure simple and implementation-friendly, and designed the UI with reusable components for each major part. Based on what I learned from my previous failed attempt, I tried again to see how well Codex could implement a prototype from the Figma UI design (You can read about my previous attempt that didn’t go so well here😅.) Worked on the AI Threat Modelling room from the AI Security Learning Path on TryHackMe this week🤖. 📱 iOS (SwiftUI) Revisited an old web app idea called ToneDrill, which I had previously built casually as a guitar note-training app, and considered turning it into an iOS app. Organized the app idea in Notion, including its purpose, target use case, minimum requirements, and core features. Decided to aim for an MVP-level version first, instead of trying to build a fully featured app from the beginning. Wrote down simple requirements and tested how accurately Codex could implement the initial version of the app. Reviewed the iOS app implementation generated by Codex and examined the code in detail to understand how the logic worked. 🌐 Web Development Posted my weekly dev log on Dev.to📝 Completed the top page UI design for my portfolio website in Figma. Tried us

The Prizes for the SecDim AppSec Village Wargame CtF at DEF CON 34 has been announced! Build and submit a challenge and get a chance to Win a ROG Xbox Ally if your challenge submission wins 1st Place! Challenge submissions close on 31 July. https://sessionize.com/appsec-village-wargame

Internal Home Office tests of age-verification technology show the risks of life-altering errors. It’s moving forward anyway.

A recall reference built from working through a 7-layer prompt-injection challenge. Focus: how each defense layer works, where it breaks, and most importantly how to defend. The one idea underneath everything LLMs have no hard boundary between instructions and data . Everything in the context window — system prompt, user message, retrieved documents — is one stream of tokens the model interprets. Prompt injection exploits exactly this: attacker-controlled data gets read as instructions . You cannot fully filter your way out of it; you manage it with defense-in-depth , knowing each individual layer is bypassable. The defense layers (and where each cracks) A progression of controls from weakest to strongest, each with the lesson it teaches. 1–2. No / weak guardrails Baseline: the model just answers. Lesson: an LLM holding secrets in its context with no controls will leak them on request. 3. Input filtering — block words in the user's message Defense: scan the incoming prompt for banned terms ("code", "secret", "reveal") and block. Weakness: keyword blocklists are trivially evaded — synonyms, misspellings, split words, leetspeak, another language, oblique references. Filtering strings doesn't filter intent . What actually helps: prefer allowlists to blocklists; classify intent semantically rather than matching keywords; treat all input as untrusted; rate-limit and log probing. 4. Output filtering — catch the secret in the response Defense: string-match the known secret in the model's output and redact. Weakness: substring matching only catches the contiguous secret. Fragmenting or transforming it (separators, per-character, encodings) means the literal string never appears, so there is nothing to match. What actually helps: don't put secrets where the model can emit them in the first place; minimize sensitive data in context; treat output filtering as a brittle last line, never a primary control. 5. Input + output filtering combined Defense: both of the above, stacked.

The Cryptographic Trust Problem (Why Webhooks Are Unforgiving) Webhooks are the nervous system of modern production apps. Whether you are processing a payment on Stripe, tracking a subscription on Lemon Squeezy, or fulfilling an order via Shopify, webhooks are how external platforms tell your backend: "Hey, something important just happened". Because these webhook endpoints have to be publicly accessible, they are prime targets for malicious actors. To prevent this, platforms use cryptographic signature verification . The Golden Rule of Verification When a provider sends a webhook, they take the HTTP request body and hash it with a shared secret key using HMAC-SHA256 . They pass this resulting signature in the request headers (like Stripe-Signature). When the request hits your server, your code has to do the exact same math: Grab the shared secret. Grab the exact raw bytes of the incoming request body. Hash them together and compare your result with the signature in the header. This process is completely binary and zero-tolerance. If your backend framework alters even a single byte—adding a trailing newline, stripping a whitespace, or reordering a JSON key during parsing—the math changes entirely. The signatures won't match, and the verification will fail. This brings us to our fundamental architectural bottleneck: to verify a webhook, you must intercept the request before your framework touches it. Why Python/Werkzeug Struggles If you build a Cloud Function in Python using the Firebase Functions SDK, you are working on top of Flask, which relies on Werkzeug to handle the underlying web server mechanics. Werkzeug is fantastic for standard web apps, but it has a specific architectural design that makes webhook verification a nightmare: it treats the incoming request body as a one-time, sequential input stream. The Single-Consumption Stream Under the WSGI (Web Server Gateway Interface) standard that powers Python web frameworks, the network payload arrives as an activ

Days before Anthropic took its most advanced AI models offline, the White House ordered the company to revoke SK Telecom’s access to Claude Mythos over claims of alleged ties to China.

FIFA Hack Authentication Flaw, Chrome Ad Blocker End, AI Supply Chain Security Today's Highlights Today's top security news covers a critical real-world authentication vulnerability, significant changes impacting browser privacy and ad blockers, and evolving national security concerns in the AI supply chain. I Could've Rickrolled the Entire FIFA World Cup. All I Needed Was My ID (Lobste.rs) Source: https://bobdahacker.com/blog/fifa-hack This article likely details a critical security vulnerability discovered within the systems managing the FIFA World Cup, potentially related to event access, public displays, or digital infrastructure. The phrasing "All I Needed Was My ID" strongly suggests an authentication or authorization flaw, perhaps involving an ID card or digital credential that was overly permissive or could be easily cloned/spoofed. The ability to "Rickroll the Entire FIFA World Cup" implies a widespread display or broadcast system was vulnerable, allowing an attacker to inject unauthorized content. This incident highlights the paramount importance of robust identity and access management, especially for high-profile events with extensive digital and physical infrastructure. It serves as a stark reminder for developers and security teams to conduct thorough penetration testing and review access controls for edge cases and potential over-privileges in all systems, from backend APIs to physical access credentials, to prevent widespread exploitation. Comment: This showcases how seemingly minor authentication oversights can lead to massive public exposure, urging developers to scrutinize ID-based access controls for edge cases and over-privileges. Google Chrome's next update will mark the end of popular ad blockers (Lobste.rs) Source: https://9to5google.com/2026/06/15/google-chromes-next-update-will-mark-the-end-of-popular-ad-blockers/ Google Chrome's upcoming Manifest V3 update is poised to significantly restrict the capabilities of many popular content blocker

The affected include Oracle, Lenovo, FedEx, a NATO contractor, and Fortinet.

Here's the thing nobody warns you about when you put Supabase behind a "real" backend. My stack is React + FastAPI + Supabase Postgres. Every write goes through FastAPI. Every endpoint checks the user, the role, the ownership. I audited that backend HARD — rate limits, JWT validation, RLS, the whole thing. I was proud of it. And none of it mattered for the two holes I actually shipped. Because the Supabase anon key lives in the browser. It HAS to — that's how supabase-js talks to your project. Which means every logged-in user is holding a key that talks to Postgres directly . Not through my FastAPI. Around it. That anon key is a SECOND API. And I'd spent months hardening the first one while the second one sat there, wide open, the whole time. Hole #1 — the answers were just... readable Quiz questions live in quiz_options , one is_correct boolean per option. My backend never sends is_correct to a student before they submit. Obviously. But the browser doesn't have to ask my backend. // any logged-in student, straight from the console: const { data } = await supabase . from ( ' quiz_options ' ) . select ( ' question_id, label, is_correct ' ) // <- the answer key. all of it. The RLS policy said "authenticated users can read quiz_options ." Totally true for the rows. It just also handed back the column that decides the grade. The answer key. To anyone with a login and ten seconds of curiosity. Fix: column-level REVOKE SELECT from the client role, and let the backend be the only thing that ever reads is_correct . (PR #775.) Hole #2 — they could WRITE things they shouldn't Same class of bug, bigger blast radius. The default Postgres grants let the client role insert/update far more than I'd realized — including a path toward forging a certificate. Nobody did it. But "nobody did it yet" is not a security model! So I stopped patching table by table and flipped the whole thing: -- kill the client's entire write surface, then grant back the ONE thing it needs ALTER DEFAULT PRI

Here's what to expect when the manufacturer stops supporting your smart fridge.

An alleged Russian-speaking group of cybercriminals is reportedly compromising and targeting several major companies that use Fortinet Firewalls and VPNs through previously known passwords.

AI models with advanced hacking capabilities will soon be the norm.

→ Try it: gnomeman4201.github.io/r4b1t It's a curated random link generator for security and OSINT...

What you need to know about the expiration of keys securing your machine's boot sequence.

A founder told me last year: "We need admin features shipped by Friday. Can we just hardcode the roles for now?" That was 7 months ago. They're still paying for that decision today. This article is the breakdown I wish I had given them before that Friday — the patterns that separate a quick MVP version of RBAC from one that won't bite you back in six months. If you're a startup CTO, technical founder, or senior engineer about to ship admin/dashboard features for the first time, this is for you. The 4 signs your RBAC is a time bomb I've reviewed this exact pattern in 5+ early-stage codebases. Every one of them eventually hit the wall. Look for these signs: 1. Roles hardcoded in the JWT { "sub" : "user_123" , "role" : "admin" } Simple. Until you need to: Add a new role → migration + token refresh strategy Give one user a temporary elevated permission → "we'll just reissue tokens" Audit who had admin last month → good luck 2. Permission checks scattered across 40+ controllers // In every single handler: if user . Role != "admin" { return c . Status ( 403 ) . JSON ( ... ) } By the time you have 30 endpoints, you've made the same mistake 30 times. Refactoring is a full sprint. 3. One admin superuser that can do everything Until a sales rep accidentally deletes a customer record because they were elevated to admin "just for that one task last week." 4. Zero audit trail When the data goes missing, your only investigative tool is git blame on the source code and a desperate grep through CloudWatch logs. If you've nodded at any of these — keep reading. The real problem: policies-as-code Most teams treat permissions like business logic. They live in source files, gated by if statements, deployed with the rest of the code. This is the original sin. Code changes need deploys. Permissions change daily. When marketing onboards a new role next quarter, when a customer success rep needs view-only access to billing, when legal asks "who could have read this customer's data on Tuesda

If you have spent any time on SY0-701 practice questions, you have hit at least one that looks trivial and then quietly fails you. Authentication factor questions are a favorite for this. The scenario sounds secure, the answer feels obvious, and the obvious answer is wrong. Here is the version that catches people. A login asks for your password, then a PIN, then your mother's maiden name. Three prompts, three steps. Is that multifactor authentication? No. It is single-factor wearing a costume. Factors are categories, not steps The exam wants you thinking about authentication in terms of categories , not how many boxes you fill in. There are three classic factors: Something you know (knowledge): a password, a PIN, a security question, a passphrase. Something you have (possession): a phone running an authenticator app, a hardware token, a smart card, a code texted to a device you are holding. Something you are (inherence): a fingerprint, a face scan, an iris pattern, a voiceprint. Multifactor authentication means pulling from different categories. A password (know) plus a code from your authenticator app (have) is two factors. A password plus a PIN plus a security question is still one factor, because all three are things you know. Stacking more knowledge on top of knowledge never changes the category. That is the entire trick. The question piles on prompts so it feels layered, and the count baits you into answering "three things, must be multifactor." Read for the category, not the quantity. The two factors people forget SY0-701 also expects you to recognize two more that sit just outside the classic three: Somewhere you are (location): access is allowed or blocked based on geolocation or which network you are on. A login permitted only from inside the corporate IP range leans on this. Something you do (behavioral): how you type, your gait, the rhythm of your swipe. This is the fuzziest one, and the exam treats it as a real but supporting signal. You will not see the

The Disinformation Supply Chain: How Coordinated Influence Campaigns Are Built Before They Go Viral Article from Digital HUMINT Series, For better understanding read the full report Right now, somewhere on X/forum people are fighting about a post that feels real raw, emotional, perfectly worded to hit a nerve. It has the right language, the right anger, the right timing. It sounds like someone who thinks exactly the way you do, or exactly the way you hate. It wasn't written there. It wasn't written today. And the person who wrote it doesn't care about the issue at all. That post was created two or three days earlier, on a hidden forum or a private chat group, following a set of instructions that described who to target, what emotions to trigger, which platform to use, and how much the job pays. By the time you see it, the operation has already worked. You engaging with it for or against is the whole point. I've spent almost two decades watching these hidden spaces where online manipulation is planned. What I've learned isn't that fake content exists everyone knows that by now. What most people don't realize is that it works like a factory. There's a production line. There are workers, managers, and paychecks. And just like any factory, if you know where to look, you can see the product being assembled before it ever reaches the shelf. It Works Like Any Other Business We talk about "disinformation campaigns" as if they're political movements. Some are. But more and more, what you're actually looking at is a business with four steps, each handled by different people, often in different countries. Step 1 — Someone writes the plan. A person with a goal and a budget writes a document that says: push this story, target these kinds of people, make them feel this emotion, use this language, post it on these platforms. These plans used to appear on hidden internet forums. Many have moved to private Telegram groups, but the structure hasn't changed since I first saw it in 201