标签：#SEC

Cloudflare recently introduced Precursor, a client-side behavioral analysis engine that continuously evaluates session interactions, such as mouse movements and keyboard timing, to improve detection of sophisticated bots and AI agents without relying solely on one-time challenges like CAPTCHAs. By Renato Losio

Originally published by InvisibleHill Research . This cross-post preserves the original research cut-off and source list. Research cut-off: July 30, 2026. Miner signaling is a live metric and may have changed after publication. BIP 110 begins with a problem that many Bitcoin users can recognize. A miner can collect a one-time fee for including an image, token payload, or other arbitrary data, while thousands of node operators absorb the cost of downloading, validating, and sometimes storing it. The proposal's authors see that mismatch as a subsidy for data storage and a threat to Bitcoin's use as money. Their answer is a temporary soft fork. For about one year, BIP 110 would make several currently valid transaction structures invalid under consensus rules. It would cap OP_RETURN outputs at 83 bytes, limit many data pushes and witness items to 256 bytes, restrict large output scripts and Taproot control blocks, and disable several Taproot upgrade paths and script features that can carry data. Adam Back agrees with the premise more than his opposition sometimes suggests. He has said that Bitcoin is about money and that spam has no place in its timechain. He also designed Hashcash to make spam costly. His objection is to the remedy. In Back's view, an annoyance that fits inside Bitcoin's existing block limit does not justify a contentious consensus change, especially one that can be bypassed, can interfere with legitimate scripts, and has not earned technical or economic agreement. That distinction is the center of the debate. BIP 110 asks whether Bitcoin should discourage an unwanted use through local policy and fees, or declare some forms of that use invalid for everyone. Back's case is stronger on this question. The proposal identifies a real externality, but it offers an asymmetric bargain: incomplete filtering in exchange for a new consensus precedent, a more complicated upgrade path, and a material risk of a minority chain. A policy dispute became a consensus pro

Metabase Unauthenticated SQL Injection: From Admin Privilege Heist to Connected DB Data Theft 1. Basic Information Article Title : Metabase SQLi zero-day exploited in customer data-theft attacks Publisher : BleepingComputer Publication Date : August 7, 2026 Original Source : BleepingComputer Primary Sources : Metabase security update , GHSA-vwf4-m7j8-wcjf Related Entities : Metabase Cloud, Self-hosted Metabase, Framework, Tally, LexisNexis Vulnerability : Unassigned (as of August 7, 2026), GHSA-vwf4-m7j8-wcjf, CVSS 10.0, Unauthenticated SQL Injection Impact Scope : Affected unpatched versions of Metabase 0.58 to 0.63. Minimum safe versions are 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, and 0.63.5 Severity : Critical Metabase has confirmed active exploitation. Framework and Tally reported unauthorized access and data leakage on August 3日起. Metabase Cloud is already patched, but self-hosted environments require manual updates. 2. Executive Summary This is an actively exploited attack where threat actors inject SQL without authentication into the public password reset API to gain Metabase administrator privileges. They then obtain and export connected database credentials and viewable data. 3. Attack Flow Chain A: Unauthenticated SQLi to Admin Privilege The attacker searches for Internet-facing Metabase instances. They send a crafted POST request to /api/session/reset_password . They inject arbitrary SQL into the Metabase application database. They gain administrator access. They send a GET request to /api/user/current to verify a valid administrator context. Chain B: Database Credential and Data Theft Using admin privileges, they list API keys, administrators, and connected DB settings. They retrieve connected database credentials stored in Metabase. Metabase queries and exports data within allowed limits. They modify settings or accounts as needed to maintain future access. Confirmed Real-World Impact Framework: Stole names, emails, login IPs, billing/shipping addre

VMware ESX Shell Obfuscation: 21 Techniques Work with BusyBox and Bypass Plaintext Keyword Detection 1. Basic Information Article Title : CrowdStrike Threat Hunts for Shell Command Obfuscation on VMware ESX Publisher : CrowdStrike Blog Publication Date : August 7, 2026 Original Source : CrowdStrike Associated Threat Groups/Malware : SCATTERED SPIDER, BlackBasta, Royal/BlackSuit, Akira, shinysp1d3r (mentioned as known examples of ESX targeting) Related Products : VMware ESX/ESXi, BusyBox, awk, ESX shell telemetry, syslog Test Environment : ESX 7.0.3 build-20036589, VMware-bundled BusyBox CVE : None. This is defensive research and does not report the use of these 21 techniques in actual attacks. Severity : High 2. Executive Summary This research demonstrates that 21 types of shell obfuscation—such as escapes, character generation, invisible Unicode, crypto-like transformations, host-specific keys, and VMFS masquerading—work on VMware ESX BusyBox. These techniques successfully bypass plaintext keyword detection like esxcli . 3. Attack Flow Common Chain: Obfuscation Execution on Compromised ESX An attacker gains ESX shell or equivalent command execution rights through a separate vector. The attacker builds the target command using escapes, variables, awk, Unicode, or crypto-like transformations. The shell log saves the string before expansion and analysis. The BusyBox shell expands and decrypts the command into plaintext at runtime. The attacker manipulates VMs, syslog, and host settings using esxcli , vim-cmd , sh , etc. Keyword-only detection misses the obfuscated strings. Chain A: Example of Disabling or Modifying Syslog Hide esxcli using printf hex/octal or ANSI-C quoting. Execute esxcli system syslog config set --reset=loghost after expansion. Reset the forwarding destination, potentially reducing visibility for the monitoring team. Chain B: Host-Specific / Anti-Sandbox Execution Retrieve the ESX build number, hostname length, firewall status, and running VM count.

Passwords are broken. They get leaked in database breaches, reused across platforms, and phished through clever domain spoofs. While Multi-Factor Authentication (MFA) helps, standard SMS or OTP codes still leave major security gaps. Enter Passkeys : a modern authentication standard built on top of WebAuthn and FIDO2 specifications designed to eliminate shared secrets entirely. Here is a dive into the underlying cryptography, architectural flow, and why passkeys are inherently phishing-proof. The Core Concept: Asymmetric Cryptography Traditional authentication relies on shared secrets . Both you and the server know your password (or a hashed version of it). To verify who you are, you send that secret over the network. Passkeys replace shared secrets with asymmetric (public/private key) cryptography : Private Key: Generated locally on your device and stored inside a Hardware Security Module (like Apple's Secure Enclave, Android's Titan chip, or a YubiKey) or an end-to-end encrypted sync service (iCloud Keychain, 1Password, Google Password Manager). It never leaves your device unencrypted. Public Key: Registered with and stored by the website (the Relying Party). It is completely public and mathematically useless to an attacker on its own. Architectural Breakdown: How It Works Passkey operations consist of two cryptographic phases: Registration and Authentication . Phase 1: Registration (Generating the Keypair) When you create a passkey for a service (e.g., app.example.com ): Challenge Request: Your client initiates registration. The server generates a cryptographic challenge (a high-entropy random string) and sends it back alongside origin metadata ( RP ID ). Local Verification: Your browser hands this request to the OS/authenticator, which prompts for user verification—biometrics (Face ID/Touch ID/Windows Hello) or a hardware PIN. KeyPair Generation: Once unlocked, the hardware generates a unique keypair bound exclusively to app.example.com . Public Key Registration:

An inference key is a payment instrument with an API. That is the property that makes it different from most credentials you manage: the person who steals it does not need your data to profit, because the key itself buys something they want. What makes an inference key different It is directly monetisable. A stolen database credential needs a buyer for the data. A stolen inference key is resold as capacity within hours, and automated scanners harvest public repositories continuously looking for exactly this. The loss accrues while you sleep. Usage-based billing means the damage is a function of elapsed time and rate limit, not of a single event. This is the argument for hard caps over careful monitoring. It is passed around more than most secrets. Notebooks, evaluation scripts, a colleague’s laptop, a CI job, an agent’s own environment. Every one of those is a copy you do not control. The blast radius is often the whole account. Where a provider offers one key with full access, a leak is total. Where it offers scoped keys, use them — this is the single biggest lever available. Leak paths specific to AI applications Generic advice — do not commit secrets, use a manager — is correct and widely published. These are the paths that only exist because there is a model in the system, and they are the ones that survive a conventional review: The key in the context. A key pasted into a system prompt so a tool “has access to it”. It is now one paraphrase from the transcript, and the transcript is stored. Traces and observability. LLM tracing tools capture full request bodies by default. If a header, a tool argument or an environment dump ends up in a span, your key is in a third-party dashboard with a broader access list than your secret manager. Prompt and response logs. Same problem, your own infrastructure. A logger that prints the request object on error will print the Authorization header. Evaluation datasets. Captured production traffic reused as an eval set, then share

Researchers found common points of failure, like software used to organize and display web content, could have allowed hackers to run riot through government websites.

OpenAI says it is pausing "internal activities" around an in-development AI model, Astra, because it doesn't yet meet new security standards the company is putting in place. The announcement follows its recent disclosure that OpenAI models accidentally hacked Hugging Face. Anthropic and Meta have also since admitted that they had AI models that went rogue […]

The EU AI Act's Article 50 transparency rules went enforceable on August 2, 2026. If you ship a generative AI feature that touches EU users, you now owe the regulator a machine readable marking on your output. The obvious shortcut, drop a C2PA manifest and call it done, does not survive contact with production. Here is what actually works, with the code to make it real. The Two Layer Reality Article 50(2) requires effective, interoperable, robust, and reliable marking. The EU Code of Practice interprets that as at least two layers: signed metadata (C2PA) plus imperceptible watermarking (SynthID or equivalent). Fingerprinting is optional layer three. The reason for two layers is not bureaucratic. It is a screenshot. C2PA lives in a JUMBF metadata box. X strips it on upload. CDNs strip it during optimization. Screenshots destroy it entirely. Microsoft admitted this openly in its February 2026 Media Integrity report: preventing every attack on provenance is not possible. Invisible watermarks embedded in the pixel content survive those operations but carry very little information. You need both. Generating a Signed C2PA Manifest (Node) // npm install c2pa-node import { createC2pa , ManifestBuilder } from ' c2pa-node ' ; import { readFile , writeFile } from ' node:fs/promises ' ; const c2pa = createC2pa (); async function signGeneratedImage ( inputPath , outputPath , generationMeta ) { const asset = { buffer : await readFile ( inputPath ), mimeType : ' image/jpeg ' }; const manifest = new ManifestBuilder ({ claim_generator : ' firesafe/1.0 ' , format : ' image/jpeg ' , title : ' ai-generated-image.jpg ' , assertions : [ { label : ' c2pa.actions ' , data : { actions : [{ action : ' c2pa.created ' , digitalSourceType : ' http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia ' , softwareAgent : generationMeta . modelName , }], }, }, { label : ' com.firesafe.generation ' , data : { model : generationMeta . modelName , modelVersion : generationMeta . modelVer

Hackers employing AI in their tactics are finding ways to exploit vulnerabilities that didn't even exist before.

Framework told "all" of its customers that hackers accessed their names, email addresses, phone numbers, and physical addresses in a data breach.

TL;DR What: Gammu SMSD — the daemon behind a huge number of SMS gateways, alerting rigs and 2FA senders — runs an operator-configured hook every time a text arrives. With the Files backend and RunOnReceive enabled, the SMS sender ID was escaped for use as a filename but not for the shell , and then appended to a /bin/sh -c command line. A sender ID containing shell metacharacters executed arbitrary commands as the gammu-smsd user. Impact: Remote, unauthenticated code execution triggered by sending a text message. Commands run with the daemon's privileges. Missing neutralization of special elements in an OS command (CWE-78). Fixed in: Gammu 1.43.3 . Advisory GHSA-9vjj-v46c-c5qf , published 25 July 2026, rated High (8.1) , credited to me as reporter. CVE requested, pending GitHub assignment. Why you should care Most command-injection bugs need the attacker to already be talking to your HTTP API. This one needs a phone number. Gammu SMSD sits on the receiving end of a modem or GSM dongle. Hospitals use it for on-call paging, monitoring systems use it for SMS alerts, and plenty of small shops use it as the cheap half of a 2FA setup. A very common configuration is: store incoming messages as files (the Files backend ), and run a script whenever one arrives ( RunOnReceive ) — to forward it, log it, or trigger something. The input to that script comes from the outside world over the cellular network. The sender doesn't authenticate to anything. And on many networks the sender ID is an arbitrary alphanumeric string , not a phone number — that's how banks send texts that say "HSBC" instead of a number. Alphanumeric sender IDs are attacker-controllable, and they can carry the exact characters a shell treats as syntax. That is the whole bug: a value from a text message reaches /bin/sh . The setup Gammu SMSD's Files backend writes each received message to a file whose name includes the sender. To keep that filename legal, it runs the sender ID through an escaping function first

OpenAI is sharing preliminary cybersecurity evaluations for Astra and the steps we’re taking to strengthen safeguards and security controls.

In the Kimi test, the sandbox designed to contain the experiment was not properly configured.

1. Language Architecture in Ghidra When Ghidra loads an architecture (such as the MOS 6502), it parses the .ldefs manifest file, which declares metadata and binds three foundational specification pillars: The .pspec (Processor Specification): Defines the processor’s hardware context. It declares special-purpose registers (e.g., stack pointer SP , status/flags registers), default memory maps (RAM, ROM, I/O), and hardware interrupt vectors. The .cspec (Compiler Specification): Defines the ABI and calling conventions (e.g., parameter passing mechanisms), stack alignment rules, and return value handling. This is the critical building block enabling the decompiler to reconstruct assembly into readable C code. The .sla / .slaspec (SLEIGH Specification): .slaspec : The human-readable source file describing the instruction set architecture (opcodes, instruction formats, and p-code semantics). .sinc (SLEIGH Include): Modular inclusion files (typically used to split complex architectures like ARM or x86, or isolate instruction subsets like Thumb). Given the simplicity of the 6502, everything is defined directly within the .slaspec file. .sla : The compiled binary version of the .slaspec (generated by the Sleigh compiler). Ghidra loads this compiled .sla file into memory at runtime for optimal performance. 2. The Challenges of Reverse Engineering Undocumented Binaries When dealing with a binary compiled for an undocumented processor, Ghidra's default paradigm faces major limitations: The .slaspec file is unavailable. Ghidra attempts to aggressively disassemble everything. Analyzing an undocumented target requires a strict two-phase approach. 3. Missing .slaspec File Without a valid .slaspec definition, Ghidra renders ?? for every opcode. The primary objective when tackling an unknown CPU is precisely to reconstruct this missing .slaspec specification. 4. Overcoming Ghidra's Aggressive Disassembly By default, Ghidra (like most disassemblers) employs an exhaustive strategy (usin

The most consequential bug in this project had been there since the beginning, survived several full end-to-end runs, and was reported as a PASS every time. ✓ PASS slow-and-low detected within 30m (7.3m), never exceeding legit rate That line is true. The scorer flagged it correctly, well inside the bound. What the line doesn't say is that the attacker was served every single request it ever made . Zero non-allow decisions, across the entire scenario. Detected and never once stopped. This is one instance of a pattern that accounts for more real bugs in this project than every other cause combined: a component contributes nothing, no error is raised, and every surrounding number stays plausible. The bug The scorer computes windows at 1m, 5m and 1h, and publishes each result to a per-client key in Redis and OPA. Each result. To the same key. So the last writer won. And 1-minute windows close most often, so they always won. slow-and-low issues about two requests a minute. Its 1m windows fall below the minimum request count and score zero. Its 5m and 1h windows accumulate the miss ratio that earns a deny . Every one of those zeroes immediately overwrote the deny. The entire premise of a multi-scale pipeline — that different attacks are visible at different scales — was silently violated by the publication step. Any detection that only appeared at a coarser scale was discarded. The fix is a roll-up: publish the most severe verdict across window sizes within the freshness horizon the policy already uses. Afterwards, the same attacker is denied on 24–31 of its 44 requests. Why it survived so long Because the report could not express it. Detection latency was computed as the earlier of two very different facts: the scorer's first non-allow window, and the gateway's first non-allow decision. Printed under one heading — detected — a client that was noticed but never touched looked identical to one that was noticed and blocked. A report that averages over the distinction you ar

Detection produces a number. Something has to turn that number into a response, and the response has two hard constraints that pull against each other: It must be proportionate . A score of 55 is not a score of 95, and treating them the same means either blocking clients you shouldn't or serving attackers you shouldn't. It must be invisible . An attacker who learns they were detected changes tactics, and you've converted a detection into a training signal for them. The second constraint rules out most of the obvious implementations of the first. The ladder Six tiers, evaluated in Rego, driven by the pushed risk score plus the gateway's own fast-path signals: allow → log → throttle → step_up → deny → revoke The policy is small enough to read in full, and mirrors the scorer's thresholds exactly: score_tier := "deny" if { score_fresh ; score_entry . score >= 85 } score_tier := "step_up" if { score_fresh ; score_entry . score >= 70 ; score_entry . score < 85 } score_tier := "throttle" if { score_fresh ; score_entry . score >= 50 ; score_entry . score < 70 } score_tier := "log" if { score_fresh ; score_entry . score >= 30 ; score_entry . score < 50 } final_tier := fast_tier if { tier_rank [ fast_tier ] >= tier_rank [ score_tier ] } final_tier := score_tier if { tier_rank [ score_tier ] > tier_rank [ fast_tier ] } The final decision is the more severe of two independent signals: the scorer's composite, and the gateway's own sub-second guardrails. The second exists because windowed scoring cannot react faster than one window, and a flood needs stopping before then. Fail open, deliberately # FAIL-OPEN: when the risk-score data is missing or stale we allow (with a # logged reason) rather than deny. This is the choice most likely to get an argument, so here's the reasoning. This is a detection layer bolted onto a production API. If the scorer, the pipeline, or the data path between them breaks, failing closed takes the real API down for every legitimate integration — a self-i

Every signal in the previous articles is statistical. They weigh evidence, they have thresholds, they can be argued with. Honeytokens are different in kind. A honeytoken is a record that does not exist and was never given to anyone . Nothing legitimate can ask for it, because nothing legitimate has ever held a reference to it. A request for one isn't suspicious — it's proof that someone is guessing or working from a stolen list. That makes it the highest-confidence signal available, and worth building carefully. Derivation: make the decoy recognise itself The obvious implementation is a table. Generate decoy IDs, store them, and check every miss against the table. That has two problems. It puts a database lookup in the request path on every miss — and misses are exactly what a flood produces. And it doesn't tell you whose decoy was tripped without another join. Instead, derive them: export function honeytokenFor ( clientId : string , n : number , generation = 0 ): string { const mac = createHmac ( ' sha256 ' , config . honeytokenSecret ) . update ( ` ${ clientId } : ${ generation } : ${ n } ` ) . digest (); return uuidFromBytes ( mac . subarray ( 0 , 16 )); } Three properties fall out of this, and they're the whole design: Recognition is stateless. Given any ID and any client, recompute the client's decoy set and check membership. No lookup, no cache, no round trip. The gateway precomputes each known client's set at startup into a Set and membership is O(1). Attribution is automatic. The client ID is inside the derivation. There is no "which client did this decoy belong to?" question — a decoy for integration-acme is not a decoy for anyone else, and cannot be. If a decoy seeded into acme's scope is requested by a different credential, that's information too. They're format-identical to real IDs. The output is shaped as a v4 UUID — correct version and variant nibbles — so it is indistinguishable from a real documents identifier: export function uuidFromBytes ( bytes

Every anomaly detector answers one question: compared to what? That comparison, the baseline, is where I lost the most time on this project, and every failure had the same signature. Nothing errored. No test went red. The numbers stayed plausible. The detector just quietly stopped detecting. Four of them, in the order I found them. 1. The peer group contained the client it was judging Cold-start clients have no history, so they're compared against a pool of other clients' recent benign windows. Reasonable. The pool was keyed by feature: private readonly peer = new Map < FeatureKey , number [] > (); Every benign window every client produced went into the pool that client was later compared against. Including itself. So a client could define its own normality . Feed in enough windows and any behaviour becomes unremarkable — which is precisely the cold-start attacker the layer exists to catch. What made me look was not reasoning, it was an experiment that wouldn't sit still. I was trying to build a demo client that reliably landed in the middle of the response ladder, and holding the traffic shape fixed while changing only the request interval flipped the outcome between allow and step_up : gap=500ms origins=5 → allow (peak 0) gap=700ms origins=5 → step_up (peak 83) gap=800ms origins=5 → allow (peak 0) A knife edge like that is never a tuning problem. The outcome depended on a race between a client's own samples reaching the pool and the pool being consulted. Fix: key the pool per client, and exclude the client under evaluation. for ( const [ clientId , values ] of byClient ) { if ( clientId === excludeClientId ) continue ; // this is what "peer" means … } Afterwards the behaviour became monotone in the actual evidence, and identical at every request interval: origins 1 3 4 5 6 peak score 17 35 59 83 100 tier allow log throttle step_up deny Lesson: if a parameter that shouldn't matter changes the outcome, stop tuning and go find the defect. Knife edges are symptoms. 2.

Features get you a vector per window. Turning that into a decision is where the design choices are. This system scores every window three independent ways and takes the strongest single case. Each layer covers a failure mode of the others. Layer 1: guardrails Deterministic thresholds, no baseline of any kind: // Honeytoken hit — highest-confidence signal. Immediate revoke. if ( fv . honeytoken_hits > 0 ) add ( 100 , ' honeytoken_hits ' , ' … ' ); // High miss ratio — guessing IDs that mostly do not exist. if ( fv . miss_ratio >= 0.4 && fv . req_count >= 10 ) add ( 88 , ' miss_ratio ' , ' … ' ); // Sequential walk — near-adjacent IDs in order. if ( fv . id_sequentiality >= 0.8 && fv . distinct_resource_ids >= 10 ) add ( 90 , ' id_sequentiality ' , ' … ' ); // Working set that expands and never stops — the mimicry signature. if ( fv . window_size === ' 1m ' && fv . novelty_run_length >= 20 ) add ( 86 , ' novelty_run_length ' , ' … ' ); Being baseline-free is the point: they fire on a client's first window. A statistical layer needs history to say anything, so a brand-new compromised integration, one that never had a quiet period to learn from, is invisible to it. Guardrails cover exactly that gap. The deliberate omission is cardinality. There is no "distinct IDs > N" guardrail in the scorer, for the reasons in part 3 : it false-positives on legitimate bulk reads and no threshold fixes that. (The gateway's fast path does have a cardinality rule, at 150 distinct/minute — well above any realistic backfill, and it exists to stop a flood before the first window closes.) Layer 2: robust statistics Per client, per feature, per window size: keep a bounded history and score new values with a median/MAD robust z-score . Median and MAD rather than mean and standard deviation, because mean and σ are themselves distorted by the outliers you're hunting. One 5,000-request window drags a mean enough to make the next one look normal. Three things make this work in practice, and each w