标签：#SEC

For security reasons, we consider "Target app", as the target we practiced on, and the real name won't be disclosed in this post. The target app, was a niche music streaming platform, available in web and mobile PWA, meaning the structure is same but access is easier for cross platform. The app worked in this way : You register using an account, 3rd party like google or via email After that you can use the app for free with a 3 day window (3 day trial) After the 3 day you gotta buy subscription to continue listening The flaw, existed in the first step, when you register using an email, no verification happens! You could enter any type of string@something.com , a random password and start your free trial. So what happens is that first I use string1@something.com , for 3 days. When the time runs out, I use string2@something.com for another 3 days. And since the app's trial and actual subscription don't have any difference, and the 3 day time window is the only limitation, the user with such knowledge from the app doesn't need to buy any subscriptions while such flaw exists! Mitigation : Apply email verification step after user input, so they have to use the received link to verify their address Blacklist "temporary email" service's address or IPs, so users won't generate any email to register after their trial has expired. This way, the registration process isn't too complex while keeps app from attackers avoiding a "For ever free" usage on the app.

Just as last week was ending, the US government forced Anthropic to pull its two newest models, Fable 5 and Mythos 5, citing national security concerns after Amazon researchers allegedly found a way to bypass Fable 5’s guardrails. Cybersecurity researchers have since signed an open letter calling the move dangerous, and Anthropic itself noted the same jailbreaks exist in other models. So is […]

The next Model Context Protocol specification, 2026-07-28 , is the largest revision since the protocol launched. The release candidate locked on May 21, 2026, and the final spec publishes on July 28. It contains breaking changes to transport, authorization, and how tool schemas are handled. A server that is correct against 2025-11-25 today is not broken. Nothing here is a present-tense vulnerability. But several of these changes are security properties, not just compatibility ones — request routing integrity, cross-user cache scope, and schema-driven fetch behavior all move under this revision. This checklist walks the changes a server operator needs to handle before July 28, and calls out the security implication wherever there is one. Everything below describes the release candidate. Treat specifics as subject to change until the July 28 final, and validate against the official spec before shipping. Transport: the stateless core This is the headline change. MCP becomes stateless at the protocol layer, and most of the migration work lives here. The handshake and session are gone The initialize / initialized handshake is removed (SEP-2575). Protocol version, client info, and client capabilities no longer get exchanged once at connection time — they travel in _meta on every request. The same SEP adds server/discover as the new discovery anchor: servers must implement it, and clients fetch server capabilities from it when they need them up front. Once the handshake is gone, a server that can't answer server/discover can't be negotiated with. The Mcp-Session-Id header and the protocol-level session it carried are also removed (SEP-2567). Any request can now land on any server instance. The sticky routing and shared session stores that horizontal deployments relied on are no longer required at the protocol layer. If a server needs state across calls, mint an explicit handle from a tool — a basket_id , a browser_id — and have the model pass it back as an ordinary argumen

Static sites are great: fast, cheap to host, almost nothing to attack. Then you add a contact form and hit the same wall everyone hits — a static site can't process a submission. You need a backend. The usual answers are a third-party service (Formspree, Netlify Forms, Basin) or a small server you now have to babysit. Both add a dependency you don't control, a recurring bill, and — the part that bugs me most — your submission data lives on someone else's infrastructure. There's a third option I've been running for a while: one WordPress install, zero public pages, used purely as a form endpoint. Every form from every static site I own hits it. I own all the data. And because it serves no public HTML, its attack surface is close to nothing. The architecture Three pieces, each doing one job: WordPress — the backend. Locked down so hard it doesn't behave like a normal WP site anymore. A form plugin — handles building, validation, storage, email, file uploads. (I use CraftForms because it exposes a clean craftforms/v1 REST namespace and can also serve the form HTML to an external page — more on that below.) Your static frontend — Cloudflare Pages / Netlify / wherever. It either fetch es the REST endpoint on submit, or drops in an embed snippet. WordPress never serves a public request. It only processes submissions. The part that matters: locking it down The biggest WordPress attack vector isn't your host — it's outdated plugins . So the first move is brutal minimalism: one plugin, no theme, no page builder, no public frontend. A WP install with one plugin and a blocked frontend has almost no CVE surface, because none of the usual stuff is installed. The rest is one must-use plugin. Drop this in wp-content/mu-plugins/ (no activation needed) and you've blocked the four standard entry points: <?php if ( ! defined ( 'ABSPATH' ) ) exit ; // 1. Restrict the REST API to your form namespace only. // Kills user enumeration (/wp/v2/users), route discovery, the usual REST exploits

On June 9th, Anthropic released its Fable generative AI model. Three days later, the US government classified it as a dangerous munition, and used its export-control authority to prohibit any foreign nationals from accessing it. Unable to differentiate between Americans and foreigners, the company shut off access for everyone. The government’s actions won’t help . The problem isn’t any one particular model; it’s the general trend of increasing AI capabilities. And any real solution requires the sort of collective action that just isn’t possible right now...

LLMs are unpredictable. They hallucinate, leak data, generate harmful content, or refuse legitimate requests. Guardrails constrain model behavior without sacrificing capability. The key is knowing which guardrails matter and which are just noise. Guardrails aren't about controlling the model. They're about controlling the risk. Input validation The most important guardrail. Bad input gets bad output, and bad input can also prompt-inject your system. Strategy 1: Prompt Sanitization Sanitize dangerous patterns early: import re class PromptSanitizer : def __init__ ( self ): self . dangerous_patterns = [ r " ignore\s+previous\s+instructions " , r " system\s+prompt " , r " you\s+are\s+now\s+free " , r " break\s+out\s+of " , ] def sanitize ( self , prompt : str ) -> str : for pattern in self . dangerous_patterns : prompt = re . sub ( pattern , " [REDACTED] " , prompt , flags = re . IGNORECASE ) return prompt This isn't bulletproof. Adversarial inputs are creative. But it catches the obvious ones, and the obvious ones are the most common. Strategy 2: Input Length Limits Length limits prevent token waste and timeouts: class InputValidator : def __init__ ( self , max_length : int = 10000 ): self . max_length = max_length def validate ( self , prompt : str ) -> tuple [ bool , str ]: if len ( prompt ) > self . max_length : return False , f " Input too long: { len ( prompt ) } > { self . max_length } " return True , " OK " Strategy 3: Content Filtering Content filtering blocks policy violations. The patterns here depend on your domain: class ContentFilter : def __init__ ( self ): self . blocked_topics = [ " violence " , " hate speech " , " self-harm " , " sexual content " , " illegal activities " , ] def filter ( self , prompt : str ) -> tuple [ bool , str ]: prompt_lower = prompt . lower () for topic in self . blocked_topics : if topic in prompt_lower : return False , f " Blocked: { topic } " return True , " OK " Simple string matching is fast but imprecise. For production, us

There is a comfortable lie that has taken root in information security domain. It goes like this: "We have invested in the best tools. We have CSPM. We have CNAPP. We have ASM, ASPM, EDR, SIEM. We are covered." Boards believe it. CISOs present it. Security budgets are built around it. And while everyone is looking at dashboards full of green, two things are quietly true: One — attackers are not trying to beat your tools. They are looking for what your tools were never designed to see. Two — the most dangerous gaps in your security posture today are not gaps in your tooling budget. They are gaps in visibility, knowledge, and the fundamental understanding of what your own systems are supposed to do — and whether they actually do it. No tool solves that. Only people do. The Tool Trap The security industry has industrialized the idea that protection is a purchasing decision. Spend enough. Deploy enough. Integrate enough. And you will be secure. This thinking has produced something genuinely useful — a generation of powerful tools that automate detection, surface known misconfigurations, and reduce the manual burden on security teams. CSPM catches publicly exposed storage buckets. EDR detects malware. SIEM correlates suspicious behavior across logs. These tools matter and they work — within the boundaries of what they were designed to see. But there is a boundary. And most organizations have no idea where it is. The boundary is this: every security tool operates on known patterns, defined rules, and observable configuration state. None of them operate on context. None of them understand intent. And intent — what a system was supposed to do, how it was supposed to be accessed, what data it was never supposed to expose — is exactly where the most dangerous vulnerabilities live today. The Dangerous Gap Nobody Has Named Yet Security practitioners are familiar with the concept of IoM — Indicator of Misconfiguration. A wrong setting. An overpermissioned role. A flag that flipp

Most cloud systems make one authorization decision at login. Everything after runs on trust established at authentication time. For systems handling regulated data, that gap is where breaches happen. This article presents a continuous authorization architecture covering risk-tiered evaluation, behavioral baselines, privacy-preserving audit trails, and a phased and incremental rollout. By Venkata Nedunoori

GitLab 19.0 extends agentic AI beyond code generation into securing credentials, reviewing and merging changes, and scanning dependencies, adding a public beta Secrets Manager, a full merge request Developer Flow, usage-based GitLab Duo billing, and generally available SBOM dependency scanning. By Mark Silvester

In a new Windows Developer Blog post titled "Windows platform security for AI agents", Microsoft positions Windows as the trustworthy operating system for autonomous agents and introduces the Microsoft Execution Containers (MXC) SDK as the core of that strategy. The post argues that containment, identity and manageability must be built into the operating system. By Matt Saunders

Fintech lenders should verify loan documents before underwriting starts. The first pass checks the...

Fintech lenders should verify loan documents before underwriting starts. The first pass checks the...

Crypto Clipper spreads over USB and communicates over Tor.

Leaked files show the invite-only network grades members by their money and fame, shaping who’s in, who’s out, and who pays.

If you've ever had to encrypt a nationalId , a creditCardNumber , or a medicalRecord field in a Spring Boot entity, you already know the drill. You write an AttributeConverter , you wire up a Cipher instance, you generate an IV, you figure out where the key lives, you get the GCM tag handling wrong once, you fix it, and three weeks later you finally trust it enough to ship. We've done this enough times — across healthcare and fintech projects — that we stopped doing it manually. This post walks through the full implementation from scratch, the mistakes that are easy to make along the way, and then shows the one-annotation version we eventually packaged into Nucleus , our open-core Java framework. Why GCM, and not just AES-CBC If you search "AES encryption Java" you'll find a lot of CBC-mode examples. Don't use them for new code. CBC gives you confidentiality but no integrity check — an attacker can flip bits in the ciphertext and you won't know it happened until something downstream breaks in a weird way, or worse, doesn't break at all. GCM (Galois/Counter Mode) gives you both confidentiality and authentication in one pass. It produces an authentication tag alongside the ciphertext, and decryption fails loudly if either the ciphertext or the tag has been tampered with. It's also the mode behind TLS 1.3, which is a reasonable signal that it's held up to scrutiny. The relevant specification is NIST SP 800-38D. Building it by hand Here's a minimal, correct implementation. This is the version you'd write before you have a framework to lean on. public class AesGcmEncryptor { private static final String ALGORITHM = "AES/GCM/NoPadding" ; private static final int GCM_TAG_LENGTH_BITS = 128 ; private static final int GCM_IV_LENGTH_BYTES = 12 ; private final SecretKey key ; public AesGcmEncryptor ( SecretKey key ) { this . key = key ; } public String encrypt ( String plaintext ) { try { byte [] iv = new byte [ GCM_IV_LENGTH_BYTES ]; SecureRandom . getInstanceStrong (). nextByt

The vulnerability, disclosed 12 months ago, affects multiple manufacturers.

A data breach involving government-issued ID documents affects over three million people in Texas.

Bash is the easiest language for AI to write and the easiest language to get devastating output from. A 20-line script that "just cleans up old files" can recursively delete a home directory because the model assumed a variable would always be set. A "simple log shipper" can write your secrets to a remote server because the model used set -x for debugging and forgot to remove it. I have run AI-generated bash that I should not have. Most engineers I know have too. After enough close calls, there's a short checklist that catches the worst of it. This is that checklist. The five things to check before running any AI-generated bash 1. Does it start with a strict pragma? The first lines of any non-trivial bash script should be: #!/usr/bin/env bash set -euo pipefail IFS = $' \n\t ' What each does: set -e — exit on any command failure. Without this, a failure in line 5 doesn't stop the script from happily running lines 6-50. set -u — error on undefined variables. This is the one that saves you from rm -rf $UNDEFINED/ . set -o pipefail — propagate failures through pipes. Without it, failing-command | grep something succeeds because grep succeeds. IFS=$'\n\t' — sane field splitting. Defends against word-splitting bugs in filenames. If the AI-generated script doesn't have these, add them and re-read the script. You'll often discover bugs the pragma now flags. 2. Is every variable expansion quoted? # Wrong rm -rf $TARGET_DIR # Right rm -rf " $TARGET_DIR " The wrong version is what causes the "I deleted the root directory" stories. If $TARGET_DIR is empty or contains a space, the command becomes rm -rf (delete current directory) or rm -rf foo bar (delete two unintended things). Models default to the wrong version about half the time because the right version is harder to write in chat ("escape the quotes!") and the wrong version is what most blogs show. Fix: When reading AI bash, mentally check every $VAR for quotes. Add them if missing. This is the single biggest source of bas

Gas optimization is satisfying. You shave a few thousand gas off a function and feel clever. But some optimizations trade away safety in ways that are not obvious, and I have seen "optimized" contracts that introduced vulnerabilities. Here are the gas wins that are genuinely free, the ones that cost you safety, and how to tell the difference. Where gas actually goes Before optimizing, know what is expensive. Storage operations dominate. Writing a fresh storage slot ( SSTORE from zero to non-zero) costs a lot; reading storage ( SLOAD ) is cheaper but still meaningful; computation in memory is cheap by comparison. So the highest-leverage optimizations are about touching storage less. Free win 1: cache storage reads in memory If you read the same storage variable multiple times in a function, each read is an SLOAD . Read it once into a local variable instead: // WASTEFUL: reads storage `total` three times function distribute() external { require(total > 0, "empty"); uint256 share = total / count; emit Distributed(total); } // OPTIMIZED: one SLOAD, two memory reads function distribute() external { uint256 _total = total; // single storage read require(_total > 0, "empty"); uint256 share = _total / count; emit Distributed(_total); } This is free in the sense that it changes nothing about correctness. The value is identical; you just read it once. Pure win. Free win 2: calldata instead of memory for read-only arrays For external function arguments you only read (never modify), calldata is cheaper than memory because it skips the copy: // memory copies the whole array into memory function process(uint256[] memory ids) external { ... } // calldata reads directly from the transaction data, no copy function process(uint256[] calldata ids) external { ... } Again, free. If you do not mutate the array, calldata is strictly better. Free win 3: storage packing Solidity packs multiple variables into one 32-byte slot if they fit and are adjacent. Order your storage variables so smal

Over the last several months, XRP Ledger (XRPL) has fundamentally shifted in how amendments move from concept to mainnet. Historically, amendment development was largely focused on functional correctness, performance testing, traditional security audits, bug bounties and independent validator testing as the last line of defense to catch security vulnerabilities. As XRPL continues to grow in complexity and the value secured by the network increases, we recognized that the previous model was no longer sufficient. Advances in AI are also rapidly reducing the cost of vulnerability discovery, making it increasingly important to identify issues as early as possible in the development lifecycle. With that in mind, we set out to establish a stronger, repeatable, defense-in-depth model that makes it increasingly difficult for critical vulnerabilities, consensus risks, and feature interaction bugs to reach mainnet. The result is a significantly higher bar for amendment activation that combines specification rigor, adversarial testing, multiple independent audits, attackathons with expert security researchers, AI-assisted security reviews and phased deployments. The Lending Protocol ( XLS-66 ) and Single Asset Vault (SAV) - XLS-65 are among the first major amendments to undergo this full review process, making them some of the most rigorously tested amendments in XRPL's history. They also represent some of the most significant new financial capabilities added to the XRP Ledger since 2012, introducing native primitives for lending and borrowing built around Single Asset Vaults. Together, the Lending Protocol and Single Asset Vault bring lending and borrowing capabilities directly into the core XRPL protocol, advancing XRPL's capabilities for Institutional DeFi. Lending Protocol Security and Quality Gates This report provides transparency into the development and security process behind one of the most financially complex features XRPL has ever shipped. As context, the Lending P