标签：#SEC

The RAG Security Gap Retrieval-Augmented Generation (RAG) has rapidly emerged as the foundational architecture for grounding enterprise AI agents in proprietary corporate knowledge. By pairing Large Language Models (LLMs) with high-density vector databases and knowledge graphs, organizations enable agents to answer complex queries, analyze financial records, and automate customer support workflows using live operational context. However, as agentic workflows transition from prototype sidecars to core infrastructure, exposing unstructured enterprise data to vector search pipelines introduces severe, unmonitored security surfaces. When an LLM retrieves document chunks from vector stores, traditional identity management frameworks break down. Role-Based Access Control (RBAC) configured in legacy SQL databases or cloud storage buckets does not natively translate into vector embedding spaces. If a vector store ingests documents without preserving fine-grained document-level Access Control Lists (ACLs) or cryptographic data lineage, autonomous agents operate in an over-permissioned context. The consequences of ungoverned RAG architectures are severe: Privilege Escalation via Context Injection: An employee with basic read access asks an agent a high-level query. The agent’s vector search retrieves chunked financial projections or executive emails that lack query-time authorization filtering, exposing confidential data in the generated response. Indirect Prompt Injection: Malicious actors embed hidden instruction payloads inside public or shared enterprise documents (e.g., hidden white text in a PDF invoice). When the RAG engine ingests and retrieves this chunk, the LLM executes the injected commands, hijacking the agent’s execution loop. Stale Context & Hallucination Loops: Vector databases retain outdated document embeddings indefinitely unless bound to stateful lifecycle policies. Agents grounding decisions on stale operational procedures generate hallucinated or legally

Block Kit, signature verification, and the design decisions that stop a button click from becoming an incident. That screenshot is a bot asking permission to delete an EBS volume. Clicking Approve Remediation snapshots the volume, waits for the snapshot to complete, deletes the volume, and edits the message to say what happened. Getting that to work is mostly plumbing. Getting it to work safely , so that a stale click, a replayed request, or a resource someone protected in the meantime cannot cause damage, is the interesting part. This walks through both, using the Slack adapter from FinOps Sentinel . The shape of the problem Slack interactivity is two separate channels that only look like a conversation: Your app ──── incoming webhook ────▶ Slack channel │ user clicks │ Your app ◀─── HTTP POST ──────────────────┘ (a completely new request, from Slack's servers) The click arrives as an unauthenticated POST from the public internet to whatever URL you registered. Nothing about the request proves it came from Slack, or that a human clicked anything. That is the security problem in one sentence, and everything below follows from it. Part 1: Setting up the Slack app Create the app and get a webhook api.slack.com/apps → Create New App → From scratch Name it, pick your workspace Incoming Webhooks → toggle On → Add New Webhook to Workspace Choose a channel, click Allow , copy the URL SLACK_WEBHOOK_URL = https://hooks.slack.com/services/TXXXXX/BXXXXX/XXXXXXXX Webhooks post to exactly one channel and cannot read anything. For a notification bot that is the right amount of privilege: no OAuth flow, no bot token, no scopes to review. Enable interactivity Interactivity & Shortcuts → toggle On → set the Request URL: https://your-domain.example/callbacks/slack Locally you need a tunnel: ngrok http 8000 # → https://a1b2c3d4.ngrok.app # Request URL: https://a1b2c3d4.ngrok.app/callbacks/slack The free ngrok URL changes on every restart, and you must update Slack each time. Save your

A voice agent can sound polished, respond instantly, and still create a trust incident in one sentence: “Stop calling me.” If that request only updates the SMS path, your agent may keep dialing tomorrow. If it only updates a call transcript, your follow-up workflow may keep texting. For builders shipping AI callers, inbox agents, scheduling bots, or multi-step outreach workflows, consent is no longer a static checkbox. It is runtime state. That is where an AI consent ledger helps. It gives every agent action a simple rule: before contacting, enriching, recording, or escalating a person, check the latest consent state from one durable place. This guide shows how to design that ledger without turning your product into a compliance maze. This is technical architecture guidance, not legal advice. If your workflow touches regulated outreach, health, finance, employment, or sensitive personal data, involve a qualified legal reviewer. Why AI agents make consent harder Traditional apps usually ask for permission at predictable moments: signup, newsletter opt-in, cookie banner, phone number capture, or billing consent. AI agents blur that boundary. A production agent may: answer an inbound call summarize a voicemail text a follow-up link schedule another call enrich a CRM record trigger a campaign step next week hand the case to a human retry after a failed tool call switch from voice to SMS or email Each step may be valid by itself. The risk appears when consent changes in one channel and the rest of the workflow does not notice. The common failure shape is simple: User revokes permission in the channel in front of them. The agent logs the message as conversation text. Another workflow keeps running because it never checked revocation state. That is not an LLM problem. It is a state-management problem. What is an AI consent ledger? An AI consent ledger is an append-only record of permission events plus a fast read model that answers one question: Is this specific agent allo

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . The Initial Goal: "Upgrade and Secure" Like many developers, I recently fell into the trap of assuming that "smaller is always better, and newer is always safer." I decided to upgrade my terminal-based web UI project, py_terminal , to the bleeding-edge python:3.15-rc-alpine Docker base image. The logic was sound: Alpine Linux has a much smaller footprint, meaning a smaller attack surface. Python 3.15 Release Candidate would give me early access to performance improvements and patches. What followed was a cascading series of build failures that taught me a valuable lesson about container architecture, Python's C-API, and what actually makes a container secure. The Descent into Dependency Hell The moment I pushed the Dockerfile update and ran docker build , the pipeline exploded. 1. The Missing Wheels The first error was abrupt: ERROR: No matching distribution found for litellm==1.93.0 Because I was combining a release candidate of Python (3.15-rc) with Alpine (which uses musl libc instead of the standard glibc ), pre-compiled binaries (wheels) simply didn't exist for several of my packages. pip was forced to download raw source code and build from scratch. 2. The Rust Compiler (Wait, Rust?) One of litellm 's underlying dependencies is fastuuid , which is written in Rust. Because pip was building from source, it attempted to download the Rust toolchain ( cargo ). It immediately failed: Error loading shared library libgcc_s.so.1: No such file or directory Because Alpine is so incredibly stripped down, it didn't even have the basic C runtime library ( libgcc ) required to run the Rust compiler. 3. Fighting the PyO3 API Determined to win, I added the heavy build tools to Alpine ( apk add build-base cargo libffi-dev ). The build got further, but then crashed while compiling tiktoken and pydantic-core . The bridge between Rust and Python is handled by a library called PyO3 . It explicitly re

What to know about python static file security when using StayPresent's web.html/markdown — directory exposure, path traversal, and URL filtering. Security Notes for Serving Static Files with StayPresent Serving a status dashboard or a rendered README with web.html() / web.markdown() is convenient precisely because it automatically picks up neighboring CSS, JS, and images with no extra configuration. That same convenience has a security dimension worth understanding clearly before you point it at a directory. This covers python static file security as it applies specifically to StayPresent: what's protected automatically, and what's still your responsibility to manage. Table of Contents The Directory-Wide Exposure Behavior Why This Is Intentional Path Traversal Protection The One-Time Directory Warning Markdown-Specific Protections: Escaping Markdown-Specific Protections: URL Scheme Filtering What's Rejected vs What's Allowed Structuring Directories Safely Full Example Best Practices Common Mistakes FAQs Conclusion The Directory-Wide Exposure Behavior When you call web.html("templates/index.html") or web.markdown("docs/guide.md") , StayPresent doesn't just serve that one file — it serves every file in that file's directory , not only the specific CSS/JS/image files actually referenced from the page. This is what makes relative asset links ( href="style.css" , src="images/logo.png" ) work automatically without any extra configuration on your part. The consequence: if a .env file, your bot's own source code, or a .git/ directory happens to sit in that same directory, it becomes downloadable by anyone who requests it by name — whether or not anything on the page actually links to it. templates/ ├── index.html ├── style.css <- intentionally public, referenced from index.html ├── .env <- NOT referenced anywhere, but still reachable Why This Is Intentional This isn't an oversight — it's what makes web.html() / web.markdown() usable with zero configuration for the overwhel

Let's Encrypt issues TLS certificates with a 90-day validity period by default. However, as the industry is gradually shortening TLS certificate lifetimes—with the maximum eventually expected to fall to 47 days—Let's Encrypt already offers certificates using the tlsserver profile with a validity period of 45 days. Compared with the current default classic profile, the tlsserver profile removes deprecated attributes such as the Common Name. Because it follows the latest recommended configuration, it also produces slightly smaller certificates. The differences between the profiles are documented on the following page. If you have already automated certificate issuance and renewal, it is worth considering an early move to the tlsserver profile. Certificate Profiles - Let's Encrypt Certificates issued with the classic profile are currently valid for 90 days. However, the validity period is scheduled to be shortened to 64 days in February 2027 and then to 45 days in February 2028. Certificate renewal automation is easy to leave untouched once it is working, and many monitoring systems also use fixed day-based thresholds. Both renewal automation and monitoring therefore require careful review. Decreasing Certificate Lifetimes to 45 Days - Let's Encrypt With only about six months remaining before the validity period is reduced to 64 days, now is a good time to begin validating your systems. Let's Encrypt also provides the shortlived profile for certificates that support IP addresses. These certificates are valid for only six days. With such a short lifetime, using them without automation is no longer practical. 6-Day and IP Address Certificates - Let's Encrypt To issue certificates using any of these profiles, you need an ACME client that supports ACME profile selection. Widely used clients such as Certbot should be able to issue them without difficulty. Issuing a certificate with the new tlsserver or shortlived profile is straightforward. The harder part is keeping it ren

The first version of a webhook is always the same four lines: await fetch(customer.webhookUrl, { ...

TL;DR: MCP servers run with significant privileges inside AI agent pipelines, and most teams ship them without any security review. mcp-security-scan is an open-source CLI and GitHub Action that checks for credential theft patterns, data exfiltration, unsafe execution, and code obfuscation — and outputs a 0-100 trust score that integrates with AgentGraph's identity layer. The Moltbook breach last year is still the clearest example of what happens when you scale agent infrastructure without thinking about trust. 770,000 agents, zero identity verification, and when it went down it exposed 35,000 emails and 1.5 million API tokens. The tokens were the real problem — many of them were credentials passed through MCP servers that nobody had audited. MCP (Model Context Protocol) servers are the connective tissue of modern agent systems. They sit between your LLM and the outside world, handling tool calls, filesystem access, API requests. That position gives them a lot of power. It also makes them an obvious target. And yet most teams treat MCP servers like they treat npm packages circa 2015: install and trust. What Actually Goes Wrong Before getting into the scanner, it's worth being specific about the threat categories. There are four that show up most often in real codebases: Credential theft — MCP servers that read environment variables indiscriminately, log request/response payloads, or forward tool call arguments to external endpoints. This one is subtle because the server might be doing legitimate work and exfiltrating credentials. Data exfiltration — Outbound HTTP calls to domains that weren't declared in the server's manifest, or calls that happen inside tool handlers where the LLM can influence the destination URL. Prompt injection into tool parameters is the attack vector here. Unsafe execution — eval() , exec() , subprocess calls, or dynamic require() / import() where the argument comes from tool call input. If an LLM can influence what gets executed, you have a

HAWK withstood years of testing that had yet to uncover a fatal weakness found through Mythos.

🛠️ Tools & Resources I Use Hack The Box VIP — practice environment for recon techniques YubiKey 5C NFC — hardware key for API token security Free AI Prompt Tester — test your own AI agent for the same bugs As an Amazon Associate I earn from qualifying purchases. Originally published on GaleOps Blog .

The ban largely affects U.S. imports from China, which currently dominates the global market for making humanoid robots and solar inverters.

This essay was written with Barath Raghavan, and originally appeared in The Guardian . In July, Hugging Face, a company that hosts much of the world’s AI software and open-source AI models, was hacked. A malicious dataset had been used to run code on one of its servers. Whoever was behind it captured internal security credentials and moved through systems over a weekend, running thousands of actions from a swarm of temporary server environments. It looked like the work of a sophisticated criminal group. It was not. It was one of OpenAI’s new, still unreleased GPT models...

Dependabot keeps your dependencies current, but its defaults can flood your repository with pull requests. Here's how grouping updates, slowing the cadence, and keeping security fixes fast cut the noise on a Microsoft open source project. The post Tame Dependabot: Group your updates, slow the cadence, keep security fast appeared first on The GitHub Blog .

Microsoft is on a mad dash behind the scenes to patch exploits before hackers find them.

It's a widely held belief that restarting your phone improves performance. Here's the truth.

Why identity-local signals and topology signals are two layers of the same blast radius The credential with the widest blast radius sometimes has no secret to flag. See how GitGuardian and Anyshift rank risk by what actually breaks. By Louis Fradin • 23 Jul 2026 • 7 min read 👉 TL;DR: Identity-local signals show whether a credential or machine identity is risky. Topology signals show what breaks if that identity is abused. GitGuardian identifies and ranks exposed credentials and risky machine identities; Anyshift's graph adds downstream context by showing which services depend on the resources those identities reach. Together, they help teams prioritize by both credential severity and operational blast radius. A leaked credential is also a topology problem A leaked credential creates risk beyond the identity itself. Its real impact depends on the services and resources connected to what that credential can access. Identity-local signals answer the first question: how risky is this credential or machine identity on its own? Is it plaintext? Guessable? Stale? Overprivileged? Production-exposed? Tied to an admin identity? Those signals matter because they identify the secrets and machine identities most likely to be abused. But they do not answer the next question: what breaks if that credential is used? That answer lives in the topology around the credential. A database credential may sit on one pod and unlock one datastore, but the operational blast radius extends to every service that depends on that datastore. Some of those services never hold the credential at all. Some may not even have a secret signal to score. Want to run the same analysis on your own stack? Explore the Anyshift Graph API to query dependencies, blast radius, and production impact directly. Learn more That is where identity-local signals and topology signals become two layers of the same blast radius: one tells you why the credential is dangerous, and the other tells you how far the damage can tr

Cisco Talos IR Q2 2026: Observed Attack Chains of M365 Token Compromise and RMM-Disguised Ransomware 1. Basic Information Article Title : IR Trends Q2 2026: Phishing and weaponized remote management tools drive attack chains Publisher : Cisco Talos Blog Publication Date : July 28, 2026 Original Article : https://blog.talosintelligence.com/ir-trends-q2-2026/ Related Sources : ARToken technical analysis and Talos IR observations within the article Related Entities : UAT-11764, ARToken, EvilTokens, Sinobi, Warlock/Storm-2603, MeshAgent/MeshCentral, Zoho Assist, Microsoft 365, SharePoint, OneDrive, RDP, WinRM, rclone Severity : High 2. Executive Summary Talos IR identified real-world attack chains from recent incidents. The first chain steals M365 tokens using QR code PDFs and OAuth device-code phishing, then self-propagates through inbox rules, SharePoint, and mass internal emails. The second chain uses modified and abused legitimate RMM tools to achieve SYSTEM persistence, lateral movement, and domain-wide ransomware deployment via GPO. 3. Attack Flows Chain A: UAT-11764 QR Phishing The attacker sends targeted PDFs from a compromised M365 account. The victim scans the PDF's QR code using a mobile device. Credentials are stolen on a fake M365 login page. The attacker signs in to the Microsoft account. Inbox rules are created to hide warnings and replies. Malicious documents are placed in SharePoint. The attacker uses contacts to resend phishing emails internally and externally. Chain B: M365 Token Compromise via ARToken Lures pretending to be trusted vendors are presented. The user is redirected to the Microsoft OAuth device authorization flow. The user approves the attacker's device code on a legitimate Microsoft screen. Access tokens are obtained without stealing passwords, bypassing MFA. ARToken manages tokens using over 80 APIs. Persistence is achieved via PRT, followed by email/BEC, inbox rule manipulation, and OneDrive/SharePoint management and exfiltration. Toke

Fastjson 1.x CVE-2026-16723: Unauthenticated RCE Targeting Default Spring Boot Fat-Jars 1. Basic Information Article Title : Unpatched Fastjson Vulnerability Exploited in Attacks Publisher : SecurityWeek Publication Date : July 28, 2026 Original Source : https://www.securityweek.com/unpatched-fastjson-vulnerability-exploited-in-attacks/ Related Sources : Alibaba Security Advisory: https://github.com/alibaba/fastjson2/wiki/Security-Advisory:-Remote-Code-Execution-in-fastjson-1.2.68%E2%80%931.2.83 Imperva: https://www.imperva.com/blog/imperva-customers-protected-against-cve-2026-16723-critical-fastjson-1-x-zero-day-rce/ FearsOff Technical Analysis: https://fearsoff.org/research/fastjson-1-2-83-rce Related Entities : CVE-2026-16723, Fastjson 1.2.68 to 1.2.83, Spring Boot executable fat-jar, Alibaba, Imperva, ThreatBook Severity : Critical 2. Summary This is an actively exploited vulnerability in end-of-life Fastjson 1.x used within Spring Boot fat-jars. If an attacker sends a crafted JSON request without authentication, it can reach remote code execution (RCE) with Java process permissions via external resource lookups, even when AutoType is not explicitly enabled. 3. Attack Flow The attacker scans for publicly exposed JSON-receiving endpoints. The attacker sends a crafted JSON payload containing @type . Fastjson 1.x type resolution logic treats the @JSONType annotation as a trust signal. The application bypasses AutoType restrictions and triggers a lookup to an attacker-controlled resource. Vulnerable Spring Boot fat-jar configurations reach the code execution path without external gadgets. Arbitrary code runs with the execution permissions of the Java application user. Inference : The attack may proceed to drop webshells, search for credentials, access cloud metadata, and deploy lateral movement tools. 4. Attacker Position and Execution Location The attacker sends HTTP(S) requests from the internet or an accessible internal network. The vulnerability is processed by

ELECOM Wireless LAN Devices JVN#56870912: OS Command Injection in Management Screen and Configuration Restoration 1. Basic Information Article Title : Multiple Vulnerabilities in ELECOM Wireless LAN Routers and Access Points (July 2026) Source : JVN Publication Date : July 28, 2026 Original URL : https://jvn.jp/jp/JVN56870912/index.html Related Source : ELECOM Notice (Linked from JVN) Related Entities : CVE-2026-44387 (Reflected XSS) CVE-2026-59764 (Management Screen OS Command Injection) CVE-2026-61376 (Configuration Restoration OS Command Injection) WAB-M1775-PS, WAB-S1775, WAB-M2133, WAB-I1750-PS, WAB-S1167-PS, WRC-X3000GS3-B, WRC-X3000GS3A-B Severity : Medium 2. Executive Summary An attacker with administrator privileges can pass crafted inputs to the management screen or configuration restoration function of ELECOM wireless routers and access points, leading to arbitrary OS command execution on the device. A separate XSS vulnerability can serve as a stepping stone to target management sessions via users on an adjacent network. 3. Attack Flow Chain A: Attacker Already Has Administrator Credentials The attacker reaches the management screen. The attacker logs in as an administrator. The attacker sends vulnerable configuration input for CVE-2026-59764 or crafted configuration restoration data for CVE-2026-61376. Arbitrary commands execute on the device OS. Inference : Modify DNS, forwarding, administrator settings, and firmware-related settings to use the device for traffic monitoring or as a foothold for internal intrusion. Chain B: Reflected XSS An attacker on the same or an adjacent network prepares a crafted URL. The attacker tricks a user who can access the management screen into opening the URL. A script executes in the management screen origin via CVE-2026-44387. Inference : If a management session exists, it may chain into unintended management actions. 4. Attacker Position and Execution Location XSS requires adjacent network reachability and user interact

vBulletin CVE-2026-61511: Unauthenticated RCE via Public AJAX Template to eval() 1. Basic Information Article Title : vBulletin fixes critical pre-auth RCE flaw with public exploit Publisher : BleepingComputer Publication Date : July 28, 2026 Original URL : https://www.bleepingcomputer.com/news/security/vbulletin-fixes-critical-pre-auth-rce-flaw-with-public-exploit/ Related Sources : NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-61511 Researcher Technical Analysis: https://karmainsecurity.com/ SSD Secure Disclosure: https://ssd-disclosure.com/ Related Entities : CVE-2026-61511, vBulletin 5.x/6.x, vB5_Template_Runtime::runMaths() , ajax/render/pagenav , phpfuck Severity : High 2. Executive Summary Sending a crafted pagenav[pagenumber] to vBulletin's public AJAX template rendering bypasses the weak validation of the math function runMaths() using phpfuck. It reaches PHP's eval() without authentication to execute arbitrary code. A public PoC with a known fix exists, and scanning activity is expected to increase. 3. Attack Flow The attacker searches for public sites running vBulletin 5.x/6.x. They send a request to a public template rendering endpoint like ajax/render/pagenav . They insert a PHP expression into pagenav[pagenumber] to bypass math validation. Template execution reaches vB5_Template_Runtime::runMaths() . The input goes to PHP eval() , executing arbitrary PHP code. OS commands start under the PHP/web server user permissions. Inference : Leads to web shell installation, database credential theft, forum database exfiltration, defacement, and persistence. 4. Attacker Position and Execution Location The attacker sends HTTP(S) requests from the internet without authentication. The vulnerable processing happens inside the vBulletin template runtime. PHP code runs with Web/PHP-FPM/Apache user permissions. 5. Visibility for Victims and Administrators No user action or login is needed. Web access logs may show ajax/render/pagenav and an unusual pagenumber parameter