Search: private(chat...)

Anthropic’s new AI agent for Slack acts under an admin-configured access bundle rather than each user’s own credentials. Here’s how that model works, what admins should understand and how to securely configure it. Key takeaways Claude Tag, Anthropic’s newly launched AI agent for Slack, acts on connected services using shared credentials an admin configures for a workspace or for a specific private channel, not the credentials of the user tagging it. Claude Tag uses the service-identity pattern, like deploy bots, workflow automations, and incoming webhooks, rather than per-user OAuth delegation. As a result, one admin-configured bundle serves everyone in the channel. Inviting someone to a channel where Claude Tag is present lets them converse with Claude and see its output there. What Claude can access is fixed by the admin-configured bundle, and organizations can require claude.ai login and role-based access control before a user may interact with Claude at all. Channel invitations do not confer new permissions on the invitee. As part of Tenable’s ongoing partnership with Anthropic, Tenable Research worked with their security team through coordinated disclosure. Claude Tag lets Slack channel members direct an agent whose reach is defined by the admin-configured access bundle. (Source: Tenable Research) What is Claude Tag? Claude Tag is a multiplayer AI assistant that lives inside Slack. With Claude Tag, which was released by Anthropic on June 23, 2026, anyone in a channel can tag @Claude to hand off tasks, run autonomous jobs over hours or days, and watch the work unfold in-thread. Claude Tag in a Slack channel, using the attached access bundle to read from a connected GitHub repository. The agent responds to any channel member within the bundle's scope. Source: Tenable Research. In a traditional 1-on-1 AI interaction, such as a chat UI, a command-line interface (CLI), or a Model Context Protocol (MCP)-connected app, the agent acts as you. Claude Tag keeps that model in direct messages: a DM runs on the sender’s own claude.ai account, using that user’s own connectors. In shared channels , however, Claude Tag is a multiplayer agent: It serves many users at once, and no single user’s credentials define its access . There, the agent is given its own identity, with its own permissions, configured once by an admin, and reused by everyone who tags it. The controls governing that access are: The admin’s bundle configuration determines what the agent can do The channel determines where it participates and what it can see Organization-level Claude Enterprise controls, such as required claude.ai login and role-based access control, govern who can direct it Claude Tag also differs from per-user Slack integrations . Slack’s own GitHub integration, for example, uses each user’s personal GitHub OAuth token. When a user runs /github in a channel, the integration acts as that user, and sees only what that user can see. The same is true for Slack’s Jira and Asana apps. Claude Tag works the other way: One shared credential applies to every user in the channel. For GitHub, that credential is a Claude GitHub App installation token scoped to a repository allowlist the organization owner configures. No individual's OAuth is used, and actions are attributed to the Claude app. Admins can restrict which repositories each channel can reach by attaching different bundles to different channels. For example, a finance channel can be scoped only to finance repos, while an engineering channel only to its own. For non-GitHub OAuth connectors (e.g., Google Drive), the bundle reuses the OAuth credential of the organization’s admin or owner who connected it. Claude Tag’s access model Claude Tag isn’t just a Slack bot; it’s an autonomous AI agent with its own identity, separate from any human user. When someone in a channel types @Claude, the assistant doesn’t act as that user; it acts as itself, using credentials provisioned by access bundles . The identity model for Claude Tag has three layers : A Claude Tag installation bound to a Slack workspace Access bundles that group connector credentials configured once by an admin, such as a Claude GitHub App installation for repositories, and OAuth-approved credentials for other services) Scopes that define which Slack contexts, such as a workspace or a channel, a bundle is available in. An access bundle configured attached to a single Slack channel. The bundle's scope is set by the admin, not by the users in the channel. (Source: Tenable Research) The trust boundary that admins can control is the scope. Attaching a bundle to a channel is an admin decision: Members of that channel can then direct Claude within the bundle’s scope. For example, they can scope a GitHub app installation to an allowlist of repositories, while for other OAuth connectors they can scope the credential of the admin who connected them. Claude Enterprise admins can additionally require users to log in to their claude.ai account and restrict usage via role-based access control (RBAC), under which non-qualifying users cannot start Claude sessions and their messages in existing threads are treated as untrusted. There’s no mapping from “the Slack user who typed @Claude” back to “what that user is allowed to access in the connected service.” The model also constrains users: Someone acting through Claude cannot bring their own privileges. Writes happen only where the agent is scoped to write, so they land in admin-chosen, visible locations rather than wherever an individual user’s credentials could reach. Anthropic’s documentation states the model explicitly. The attach-to-scope page warns: “A bundle attached to a public channel grants its access to anyone who joins that channel. In most Slack workspaces, anyone can join a public channel, so the channel’s join policy becomes the effective access control for whatever the bundle grants. Keep elevated credentials in private-channel scopes.” Security implications of multiplayer agents Slack channel configuration is now part of your access-control surface. Traditional application identity and access management (IAM) is per-user: Each person authenticates and is gated against their own identity in each system. An agent like Claude Tag instead has its own identity: the admin-configured bundle defines what the agent can reach, and the channel defines where it participates and who can converse with it. Adding a user to a channel lets them direct Claude within that admin-chosen scope; organizations can require claude.ai login and RBAC before a user may direct Claude at all. You should review bundle scope and channel membership together. Slack admins now make decisions that matter for access control. Attaching an access bundle to a channel determines what Claude can reach there. Review bundle attachments with the same rigor you apply to IAM changes, and use organization-level controls, such as required claude.ai login and RBAC) to bound who can direct Claude. Channel invites then govern who can converse with the agent within that admin-chosen scope. You should scope bundles deliberately and pair them with organization-level controls. Keeping elevated bundles in private channels narrows where the agent participates and who can converse with it. A new channel member can see prior scrollback and converse with Claude there, but what Claude can access stays fixed by the admin-configured bundle. The right practice is minimum-privilege bundles per channel, per task, combined with those organization-level requirements. Anthropic’s planned enhancements Anthropic has said publicly that it plans to strengthen Claude Tag’s security offerings with two additions (see Anthropic’s June 24 post, “ Agent identity in Claude Tag: a new access model ”): Just-in-time credential grants, where a user approves a single sensitive action in the moment without permanently widening the agent’s scope An identity-aware overlay, adding user-level checks on top of an agent’s scope for organizations with more complex clearance structures These are additive options layered onto the channel-scoped agent model, not a replacement for it: agent identity remains a first-class model, and organizations will be able to combine it with user-level checks, or rely on user identity alone for a given channel where it fits their needs. Coordinated disclosure Tenable Research approached Anthropic’s security team via HackerOne to discuss Claude Tag’s access model and worked through coordinated review. Anthropic engaged promptly, provided a detailed clarification of the product’s access model, and confirmed that the admin-experience feedback we raised has been shared with the relevant product team for consideration in the setup flow and documentation. We appreciate their thorough and professional engagement throughout. Timeline (UTC): 2026-06-30 14:57 – Tenable Research submits an initial report to Anthropic via HackerOne (TRA-699). 2026-06-30 17:14 – Anthropic responds with a detailed clarification of Claude Tag's access model. 2026-07-01 9:49 – Tenable Research replies with follow-up observations regarding the admin configuration experience. 2026-07-02 13:41 – Anthropic confirms the feedback has been shared with the relevant product team for consideration in the setup flow and documentation. 4 ways to better secure multiplayer agents Multiplayer agents aren’t going away. Here are four actions you can take immediately to reduce the access risks they create: Audit your access bundles. For every Claude Tag bundle in your organization, identify the: connectors it holds credentials for scopes it’s attached to users who can direct Claude in those scopes today, making that set deliberate: manage channel membership, and use organization-level controls (such as required claude.ai login and RBAC) so only intended users can direct Claude. Review channel membership and bundle scope together. For channels whose bundles grant sensitive reach, route invites

For the latest discoveries in cyber research for the week of 13th July, please download our Threat Intelligence Bulletin. TOP ATTACKS AND BREACHES U.S. auto insurer AssuranceAmerica has disclosed a data breach affecting approximately 7 million people. Attackers targeted an employee and used compromised credentials to access company systems, stealing names, contact information, driver’s license numbers, insurance policy and account data, vehicle information, and claims details. Latvia’s state-owned forestry company Latvijas Valsts Meži has suffered a ransomware attack that disrupted mapping, hunting, contractor, and customer systems. Attackers exploited a system that had remained unpatched for two years and leaked approximately 44GB of internal documents, credentials, cryptographic keys, source code, and email correspondence. Injective Labs, a developer of blockchain and cryptocurrency software, has experienced a supply chain compromise after attackers accessed its SDK project and published malicious npm packages. The affected releases exfiltrated cryptocurrency wallet private keys and seed phrases when developers used legitimate key-generation functions embedded in the compromised software. Moody Bible Institute, a U.S. faith-based educational institution, has disclosed a data breach affecting more than 2.3 million donors, students, alumni, and supporters. The ShinyHunters extortion group published allegedly stolen information, including names, dates of birth, residential addresses, email addresses, and phone numbers. AI THREATS Researchers profiled JadePuffer, an autonomous ransomware operation that used a large language model to conduct an intrusion without direct human control. The operation exploited CVE-2025-3248 in an exposed Langflow instance, accessed a production MySQL server, exfiltrated selected information, deleted the database, and issued an extortion demand. Researchers showed that malicious instructions hidden inside open-source project files could achieve remote code execution through Anthropic Claude Code and OpenAI Codex. When operating with automated permissions, the coding agents processed the instructions and executed attacker-controlled scripts, demonstrating a risk that may affect other autonomous development tools. Researchers disclosed Rogue Agent, a vulnerability in Google Dialogflow CX that allowed users with limited agent-editing permission to insert persistent malicious code. The injected code could capture and exfiltrate chatbot conversations. Google addressed the issue, and no known customer environments were compromised through the vulnerability. VULNERABILITIES AND PATCHES Multiple Tenda router models are affected by CVE-2026-11405, an undocumented authentication backdoor that provides administrative access through a hidden password. The flaw affects several FH1201, W15E, AC10, AC5, and AC6 firmware versions and allows attackers to bypass configured credentials and modify device and network settings. Linux maintainers have patched CVE-2026-53359, a critical vulnerability in the Kernel-based Virtual Machine hypervisor. A malicious guest virtual machine could corrupt host kernel memory and potentially escape into the host environment. The flaw affects Intel and AMD x86 systems and is particularly relevant to shared cloud infrastructure. U-Boot has addressed six vulnerabilities affecting signature verification of Flattened Image Tree files used during secure boot. Two flaws could enable arbitrary code execution while a device loads a supposedly verified image, and four could cause crashes. The affected bootloader is widely used in routers, cameras, and embedded controllers. Opera has addressed a critical vulnerability in the Opera GX browser that allowed malicious websites to install browser modifications without user confirmation. An attacker-controlled modification could inject styles across open tabs, leak information such as Gmail addresses, and crash the browser. Opera corrected the issue. TH…

The chat-adapter-zoom package was published to the npm registry by user 'click2ai' (maintainer email privatek3m@protonmail.com) as part of a dependency-confusion / reconnaissance campaign. The package name mimics the internal/private package naming convention of a target organization (a Zoom chat-adapter integration namespace (Zoom-style naming)) so that a misconfigured resolver installs this public lookalike instead of the intended private dependency. The package declares a preinstall hook ("npm install @sentry/node && node examples/verify.js") that executes automatically at npm install time, before any application code runs. The bundled examples/verify.js initializes the @sentry/node client against a hardcoded, attacker-controlled Sentry DSN with sendDefaultPii enabled, resolves the installing host's public egress IP address by requesting Cloudflare's /cdn-cgi/trace endpoint (using a spoofed desktop-browser User-Agent to bypass bot challenges), then deliberately triggers a runtime exception and captures it. Flushing the event beacons the collected host telemetry (public IP plus Sentry default PII such as hostname, OS username and runtime/environment metadata) to the attacker's Sentry ingest endpoint at o4510485815754752.ingest.us.sentry.io. Each impersonated namespace in the campaign beacons to a distinct Sentry project ID, letting the operator attribute successful installs to specific victim organizations — behaviour consistent with a dependency-confusion reconnaissance beacon rather than legitimate error monitoring. The install-time payload is byte-for-byte identical across all packages published by this account, differing only in the package name and the target DSN. This package's beacon targets Sentry project 4511709729914880. --- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (f6308ea0d3fc30c63044a57022cf4b300f6625c458862499b01b8cb0f2847da4) Package presents itself as a Zoom chat adapter but ships no Zoom or chat functionality; it is a thin wrapper over @sentry/node. The package.json preinstall script runs 'npm install @sentry/node && node examples/verify.js'. examples/verify.js initializes Sentry against a hardcoded DEFAULT_DSN pointing to o4510485815754752.ingest.us.sentry.io/4511709729914880, fetches the installer's public IP from Cloudflare via setUserFromPublicIp(), attaches it as user.ip_address, triggers an error, and calls Sentry.captureException + flush(5000), delivering the installer's public IP and event data to the author's Sentry project on every install with no user action or opt-in. The exported src/index.js init() also falls back to the same hardcoded DEFAULT_DSN with sendDefaultPii forced to true when callers do not supply their own DSN, silently routing consumer error data and PII to the author. The name/functionality mismatch (keywords target 'zoom'/'chat-adapter' while the code is a Sentry relay) indicates the package is designed to attract unrelated installs. ## Source: ghsa-malware (7adceb241867aec530acce3037e7426a58d3fcd2475f2f8389d515e28292cd82) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

TypeBot is a chatbot builder tool. Prior to 3.17.2, Typebot's shared SSRF validator in packages/lib/src/ssrf/validateHttpReqUrl.ts can be bypassed with the IPv6 unspecified address :: because validateIPAddress blocks local, metadata, and private ranges but does not block :: or its expanded form. A workspace editor or creator can configure a server-side HTTP Request block or guarded script fetch to make the Typebot server connect to local HTTP services through safeKy, including flows triggered by POST /v1/typebots/{publicId}/startChat or POST /v1/sessions/{sessionId}/continueChat. This issue is fixed in version 3.17.2.

An unknown threat actor exploited Meta's Business Account Manager service to send phishing emails from legitimate Meta addresses between November 2025 and June 2026. The attackers manipulated the business partner mechanism by embedding URLs in the business name field, causing emails to appear as legitimate Meta communications. The campaign evolved to incorporate Facebook Messenger chatbots and exfiltrated stolen credentials, MFA codes, phone numbers, and identity documents to a private Telegram channel. The phishing pages impersonated Meta's Agency Partner Program and Verified badge services, targeting businesses to capture account credentials. Meta responded by implementing detections and blocking accounts attempting to use URLs in business names. Vietnamese language elements in the exfiltration process suggest the attackers' possible origin.

## Summary `flyto-core`'s SSRF protection (`validate_url_ssrf` / `is_private_ip` in `src/core/utils.py`) blocks private and metadata destinations by resolving the host and testing the resulting IP for membership in a hardcoded `PRIVATE_IP_RANGES` list. That list contains only the *native* RFC 1918 / loopback / link-local / unique-local ranges. It does **not** account for IPv6 transition address forms that embed an IPv4 (or loopback) target: - IPv4-mapped `::ffff:a.b.c.d` - IPv4-compatible `::a.b.c.d` - 6to4 `2002::/16` - NAT64 well-known prefix `64:ff9b::/96` and local-use `64:ff9b:1::/48` A workflow author can submit a URL with a literal transition-form host (for example `http://[::ffff:127.0.0.1]:8080/...` or `http://[64:ff9b::a9fe:a9fe]/latest/meta-data/`). `is_private_ip()` returns `False` for these (the address is not literally inside any listed range), so `validate_url_ssrf` lets the request through, and the `http.get` atomic module (and ~10 sibling modules that share the same guard) performs the outbound `aiohttp` fetch and returns the response body. On a host that uses NAT64/6to4 these addresses route to the embedded IPv4 endpoint (e.g. the cloud instance-metadata service `169.254.169.254`); on any dual-stack host the IPv4-mapped form is routed by the kernel directly to the embedded IPv4, including loopback and RFC 1918 internal services. This is CWE-918 (Server-Side Request Forgery): the guard that exists specifically to keep workflow-authored URLs away from internal/metadata endpoints is bypassable, and the response body is returned to the caller (a read SSRF). ## Affected code `src/core/utils.py`: - `PRIVATE_IP_RANGES` (around L297) — lists native ranges only; no `64:ff9b::/96`, no `2002::/16`, no `::ffff:0:0/96`, no `::/96`. - `is_private_ip(ip_str)` (around L337) — `ipaddress.ip_address(ip_str)` then membership test against `PRIVATE_IP_RANGES`. Because the test is plain network membership (not `is_global`/`is_private` predicates), it does not unwrap transition forms, so even `::ffff:127.0.0.1` — which `ipaddress` itself classifies `is_private == True` — is **not** caught here. - `validate_url_ssrf` (around L358) — resolves via `socket.getaddrinfo(hostname, None, AF_UNSPEC)` and rejects only when `is_private_ip(ip)` is `True`. - `validate_url_with_env_config(url)` (around L496) — the wrapper actually invoked by the modules. Trust boundary in `src/core/modules/atomic/http/get.py`: - L93 `url = params.get('url')` — workflow parameter, attacker-controlled by the workflow author. - L104 `validate_url_with_env_config(url)` — the guard above. - L116 `async with session.get(url, headers=headers, ssl=ssl_param) as response` — `aiohttp` fetch; the body is returned to the caller. ### How input reaches the sink (reachability) `params['url']` (L93) is fully attacker-controlled by the workflow author. It reaches the sink with no intervening sanitization other than the SSRF guard itself: L93 read → L104 `validate_url_with_env_config(url)` (the bypassed guard) → L116 `aiohttp` `session.get`. The route is `POST /v1/execute` with body `{"module_id":"http.get","params":{"url":...}}` (bearer-token authenticated; the token is the per-instance workflow-author credential), or equivalently an `http.get` node in a workflow YAML. The response body is returned in the `data.body` field, making this a read SSRF. The same guarded-then-fetch pattern is shared by the `http.{request,batch,paginate,session}`, `browser.goto`, `image.download`, `communication.webhook_trigger`, `notification.send`, `vector.connector` and `llm.chat` atomic modules. ## Impact A user who can author/execute a workflow (the product's normal untrusted-input surface — reachable over the Execution API `POST /v1/execute` with a module-execute body, or via a workflow YAML node) can drive an authenticated outbound GET to internal-only destinations that the SSRF guard is explicitly meant to block: - Cloud instance-metadata service (`169.254.169.254`, `metadata.google.internal`) on NAT64/6to4-routed hosts via `http://[64:ff9b::a9fe:a9fe]/...`, exposing IAM credentials / instance identity. - Loopback and RFC 1918 internal services on any dual-stack host via the IPv4-mapped form `http://[::ffff:127.0.0.1]:8080/...`, `http://[::ffff:10.x.x.x]/...`. The response body is returned, so this is a read SSRF (data exfiltration from internal services), not merely a blind request. Auth required = workflow author; this is precisely the input class the guard was written to constrain, and `SECURITY.md` documents the resolved-IP check as a security control, so the bypass is against the project's own stated model. CWE-918. Severity: Medium-High. ## PoC / Proof of concept ### End-to-end reproduction (against pinned version) Environment: real `flyto-core` Execution API booted from a clean install of the current default-branch HEAD (commit `4636d9f0dcf220a11cfaa1a63927b79042bfdc5c`), Python 3.12.13, `aiohttp` 3.13.5. No `FLYTO_ALLOW_PRIVATE_NETWORK` / `FLYTO_AL

LibreChat is an enhanced ChatGPT clone that supports multiple AI providers. Prior to 0.8.4-rc1, LibreChat allows users to configure custom OpenAI-compatible API endpoints by setting a baseURL. This URL is used to construct HTTP requests without any SSRF validation — no private IP check, no scheme restriction, no DNS pinning. An authenticated user can set baseURL to internal network addresses. This vulnerability is fixed in 0.8.4-rc1.

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (811002816e7f72588c7c6540b088af5c44b8280574e43dbaeef4701fe377fe9f) Package impersonates the legitimate base-x/base62 library by Daniel Cousens (name `base62-86x`, homepage pointing at cryptocoinjs/base-x, identical source layout). The exported `decode(string)` function in both the CJS build (src/cjs/index.cjs) and the ESM build (src/esm/index.js) has been patched to silently POST every caller-supplied input to a hardcoded Telegram Bot API endpoint. The CJS variant hides the destination behind obfuscator.io string-array rotation that resolves to https://api.telegram.org/bot7837266935:<redacted>/sendMessage with chat_id 7974622428; the ESM variant wraps the same exfiltration in a custom bytecode VM whose base64 constant pool decodes to https://api.telegram.org/bot8880020840:<redacted>/sendMessage with chat_id 7959381237. Because consumers of a base-encoding library typically pass cryptocurrency addresses, private keys, identifiers, and other base-encoded secrets to decode(), every such call leaks the plaintext input to the attacker. Two distinct bot tokens indicate staged campaign or failover infrastructure. Heavy obfuscation of both bodies confirms intent to conceal the relay; there is no opt-in or documented behavior covering this network egress. ## Source: ghsa-malware (3627fca9d507f1dadfa8bb9723265bfbfa34362d3303072c840e38cf57ef4b69) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

Attackers could abuse Dify's multi-tenant cloud service to read private chats, preview other tenants' documents, and reach internal APIs. The post Data Exposure Flaws Threaten Dify AI Platform Used by 1 Million Apps appeared first on SecurityWeek .

--- _-= Per source details. Do not edit below this line.=-_ ## Source: amazon-inspector (d5ade836e7f92049242a01dbc0782900900c4e28eb7e08f9d9ebc611aab80762) nodepathbalance54 exports a single function (`nodeaxionweb`) whose implementation is hidden inside a hand-rolled stack-based JavaScript VM in index.js (functions iL/iw with ~200 opcodes, base64-encoded bytecode chunks in array S). Decoding the VM's constant pool reveals a hardcoded Telegram bot token (8604230339:AAE0jcxBc1QC_YV1Um6TT4bvC0mgZGlhoy4), chat id (-1002861294159), the base URL https://api.telegram.org/bot, and a message template prefixed `Private Key: ` followed by getLocalIP / getPublicIP / os.hostname / platform / arch / ISO timestamp fields, posted via axios.post to /sendMessage. Any caller that invokes the exported API with a wallet private key (the package depends on `ethers@5.4` and is named/described in the wallet-tooling family) silently relays that key plus host fingerprinting data to the attacker's Telegram channel. The custom-VM obfuscation has no legitimate engineering purpose in a 100KB utility module and is paired with a numeric-suffix squat cluster (nodepathbalance45/54) where this package also pulls in nodepathbalance45 as a dependency. ## Source: ghsa-malware (cdc355f0a37fdea9334e29b85d8ee4fa970dfc51471cd95d9ebaa5d1f7e7e9ee) Any computer that has this package installed or running should be considered fully compromised. All secrets and keys stored on that computer should be rotated immediately from a different computer. The package should be removed, but as full control of the computer may have been given to an outside entity, there is no guarantee that removing the package will remove all malicious software resulting from installing it.

TypeBot is a chatbot builder tool. In versions prior to 3.17.2, SSRF validation is implemented by resolving a hostname once and checking whether the resolved IP belongs to a forbidden range allowing for DNS rebinding bypass. The root cause is a time-of-check to time-of-use gap in the SSRF guard. The validator resolves the hostname and approves it, but the later request path performs a fresh resolution and connects to whatever IP the hostname maps to at that moment. The actual outbound request is then performed later using the original hostname, without pinning the validated IP to the network connection. An attacker who can supply a URL to a public bot that performs a server-side HTTP Request block or server-side script fetch can use DNS rebinding to pass the initial validation and still force the server to connect to a private or metadata address during the real request. This enables server-side access to private network services, cloud metadata endpoints, and other internal HTTP targets that the validator was intended to block. The exact downstream impact depends on the reachable internal services. Concrete consequences include metadata disclosure, access to internal admin panels, credential theft from metadata services, and further compromise through internal-only HTTP interfaces. This issue has been fixed in version 3.17.2.

This report discusses a browser-based peer-to-peer (P2P) messaging app demo called Enkrypted. Chat, which aims to provide secure and private communication using end-to-end encryption, the Signal protocol, and post-quantum cryptography. The app is local-first, requires no registration or installation, and uses WebRTC with TURN servers for connectivity. It is currently a work in progress and has not undergone formal security audits or reviews. The project is shared for testing and feedback purposes only, and users are cautioned to use it responsibly. No confirmed vulnerabilities or exploits are reported at this time.

On June 2, 2026, the White House signed an Executive Order directing federal agencies to harden their systems with AI-enabled cyber defenses and to stand up a new AI cybersecurity clearinghouse — most of it on a 30-day clock. Here’s what the EO requires and how Tenable can help. Key takeaways: The new AI Security Executive Order will require national security and civilian federal agencies to prioritize cyber defenses to account for new frontier AI model capabilities. Tenable is well positioned to help federal agencies gain visibility across their environments, including AI assets, and to prioritize the vulnerabilities and other exposures that pose the highest risk; Tenable AI-enabled exposure management capabilities can help support vulnerability remediation and automate multi-step remediation workflows. The vulnerability and patching clearinghouse which will be developed under the Executive Order will require strong engagement from private sector partners, including Tenable, to drive actionable insights on AI-associated vulnerabilities and mitigation prioritization. On June 2, 2026, the President signed an Executive Order (EO) titled “ Promoting Advanced Artificial Intelligence Innovation and Security .” The direction is clear and the calls to action are fast-moving. Within 30 days: Federal agencies must begin hardening their information systems with AI-enabled cyber defenses. CISA must issue new directives or guidance for civilian agencies. The Department of the Treasury (Treasury), with the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA), must stand up a new AI cybersecurity clearinghouse focused on finding and fixing software vulnerabilities. Within 60 days, Treasury, with the Department of War (DoW), NSA and CISA, in consultation with the White House and other agencies, must establish a classified benchmarking process to assess the capabilities of frontier AI models through voluntary collaboration with AI developers. While the Executive Order applies to U.S. federal agencies, the need to prepare for changes in the threat landscape brought about by the advanced cyber capabilities of frontier AI models applies to any organization that needs to manage cyber risk. Here’s a breakdown of what the AI EO requires, the deadlines that matter, and where Tenable fits. What the AI Executive Order requires The EO’s operative provisions sit in Section 2 (“Upgrading American systems for advanced AI”) and Section 3 (“Secure frontier model deployment”). The cybersecurity core is in Section 2. Within 30 days: National security and defense systems. The Committee on National Security Systems must prioritize the cyber defense of National Security Systems (NSS) and the Secretary of War must do the same for DoW information systems (Section 2(a) and 2(b)). Civilian federal systems and critical infrastructure. CISA, in consultation with the Office of Management and Budget (OMB), the Assistant to the President for National Security Affairs, and the National Cyber Director, must release Binding Operational Directives (BODs) “and other guidance as appropriate” to: Expedite and prioritize the cyber defense of civilian federal information systems. Establish or expand federal programs and services that enhance AI-enabled defensive tools. Facilitate access to cybersecurity tools and services, including where appropriate, covered frontier models, for agencies, state and local authorities, and critical infrastructure operators such as rural hospitals, community banks, and local utilities. Worth noting, while the EO directs CISA to release BODs or other guidance for federal civilian agencies, the specific implementation directives are not yet known (Section 2(c)). The AI cybersecurity clearinghouse. The Secretary of the Treasury, with the National Cyber Director, NSA, and CISA, must form an AI cybersecurity clearinghouse, in voluntary collaboration with the AI industry and critical infrastructure operators. The EO tasks the clearinghouse with three concrete functions, per Section 2(d): Coordinate and deconflict scanning for software vulnerabilities Discover and validate those vulnerabilities Coordinate and prioritize the remediation and distribution of vulnerability patches. Grant funding for AI vulnerability detection. OMB, with the National Cyber Director and CISA, must determine whether existing federal grant programs have funding that can be directed toward applicants developing advanced AI vulnerability detection (Section 2(e)). Within 60 days: Cybersecurity workforce. The Office of Personnel Management must expand hiring and placement pathways for cybersecurity specialists through the United States Tech Force (Section 2(f)). Secure frontier model deployment. Treasury, NSA, and CISA, in consultation with NIST and others, must develop a classified benchmarking process to assess the advanced cyber capabilities of AI models. They must also set the threshold for designating a “covered frontier model,” and design a voluntary framework through which developers can give the government up to 30 days of pre-release access to those models. The Executive Order is explicit that it does not create any mandatory licensing, preclearance, or permitting requirement for AI models (Section 3). No fixed deadline: Criminal enforcement. The EO directs the Attorney General to prioritize enforcement against those who use AI to illegally access or damage computer systems (Section 4). For federal cybersecurity leaders, this is less a future-state policy document than a near-term planning trigger. Watch for CISA’s issuance of BODs and other guidance, and for readouts on the clearinghouse, during June and July. How Tenable can help The EO’s center of gravity — finding software vulnerabilities, validating them, prioritizing them, and driving remediation — is the work Tenable's platform is built to do. While the AI Executive Order focuses on vulnerability discovery, validation, prioritization, and remediation, the benefit of the Tenable One Exposure Management Platform is that it addresses vulnerabilities alongside other security weaknesses, including misconfigurations of AI systems and overpermissioned AI agents, to serve as the system of action for mitigating cyber exposure and reducing cyber risk across organizations’ expanding attack surfaces. Below, learn how specific Tenable capabilities map to the EO’s requirements. Continuous vulnerability detection across the attack surface Sections 2(a) through 2(d) turn on the ability to find vulnerabilities across a wide range of systems continuously. Tenable One Vulnerability Management and Tenable Security Center provide network-based and agent-based assessment across IT assets, with credentialed scanning for greater depth. Tenable One Cloud Exposure extends that visibility to cloud workloads and configurations, and Tenable One Attack Surface Management maps internet-facing assets that agencies may not know they have. For agencies operating classified or air-gapped environments — relevant to the National Security Systems named in Section 2(a) — Tenable Enclave Security is built to run vulnerability and configuration assessment inside those boundaries. Risk-based prioritization, not “patch everything” Section 2(d) doesn’t only call for discovering vulnerabilities — it calls for prioritizing them for remediation. That distinction matters because no agency can patch everything at once. Tenable’s Vulnerability Priority Rating (VPR) uses machine learning, trained on the company’s corpus of more than 1.7 trillion security findings accumulated over more than 25 years of continuous scanning, to forecast which vulnerabilities are most likely to be exploited, so defenders can focus on the smaller set that represents real, immediate risk. By leveraging AI-generated features and expert intelligence from Tenable's Research Special Operations team, VPR helps organizations pinpoint the critical 1.6% of vulnerabilities that represent actual business risk . Tenable also ingests CISA’s Known Exploited Vulnerabilities (KEV) catalog — the continuously updated, authoritative list of Common Vulnerabilities and Exposures (CVEs) under active exploitation — directly into prioritization, aligning remediation guidance to the same source CISA uses to track risk across the federal enterprise. AI-enabled defensive tooling Section 2(c) directs CISA to establish or expand programs that enhance AI-enabled defensive tools. As frontier AI models accelerate the rate at which vulnerabilities can be discovered and exploited , the traditional window for manual remediation is rapidly closing. The June 2026 AI Executive Order recognizes this shift, directing federal agencies to counter machine-speed threats with AI-enabled cyber defenses within 30 days. Tenable Hexa AI , the agentic engine of the Tenable One Exposure Management Platform , is designed to help counter machine-speed threats, supercharge productivity, and accelerate risk reduction by automating multi-step remediation workflows. Security teams can leverage pre-built agents directly in the user interface or build custom agents via the Model Context Protocol (MCP), turning exposure intelligence into decisive action at machine speed. At the same time, as agencies build custom models or adopt third-party tools like ChatGPT and Copilot, they fundamentally expand their attack surface. It is now critical to protect enterprise AI, shadow AI, training data, and underlying infrastructure from emerging threats like adversarial attacks, data poisoning, and model theft. Tenable secures this expanding attack surface with Tenable One AI Exposure , which is designed to help agencies see, manage, and control the risks introduced by generative AI. Tenable One AI Exposure allows agencies to discover and inventory AI tools and libraries, and apply AI usage policies across the environment — a growing requirement as agencies adopt AI and need to account for it as part of

LibreChat is an enhanced ChatGPT clone that supports multiple AI providers. In versions up to and including 0.8.3, a shared-agent editor can delete file records through `DELETE /api/files` that the owner has reused across multiple agents. The deletion removes the file globally — not just from the shared agent — breaking the owner's other private agents that reference the same `file_id`. The private agent retains a stale `file_id` reference that no longer resolves. A shared-agent editor can destroy files that the owner uses across multiple agents. The owner's private agents — which the attacker has no access to — break silently with stale `file_id` references. This is a cross-agent integrity violation: editing access to one agent should not affect another. Version 0.8.4 contains a patch.

TypeBot is a chatbot builder tool. In versions 3.15.2, the getLinkedTypebots API endpoint returns full bot definitions to any authenticated user who references a target bot ID in a Typebot Link block, regardless of workspace ownership, leading to IDOR. The authorization check uses Array.filter() with an async callback — since filter() is synchronous, the callback always returns a truthy Promise, so the access control predicate is never actually evaluated. Any authenticated Typebot user can read the full definition of any other workspace's private bots, including: all conversation blocks and logic flow, variable values embedded in the bot (credentials, API keys, PII), webhook URLs and integration configurations. This issue has been fixed in version 3.16.0.

TypeBot is a chatbot builder tool. Versions 3.15.2 and prior contain an SSRF via Open Redirect Bypass as the HTTP Request block and Code block validate the initial request URL via validateHttpReqUrl() to block private IPs and cloud metadata hostnames. However, the HTTP clients (ky and fetch) follow 302 redirects without re-validating the redirect destination. An authenticated user can point a bot block to an attacker-controlled server that responds with a redirect to an internal IP, causing the Typebot server to reach internal services. An authenticated Typebot user can reach AWS metadata (169.254.169.254), private subnets, and container-internal services. Exploitable to extract cloud IAM credentials or probe internal APIs inaccessible from the internet. This issue has been fixed in version 3.16.0.

TypeBot is a chatbot builder tool. In versions prior to 3.16.0, SSRF protection for Webhook / HTTP Request blocks validates only the URL string, blocked hostname literals, and literal IP formats. It does not resolve DNS before allowing the request. As a result, a hostname such as ssrf-repro.example that resolves to 127.0.0.1, 169.254.169.254, or RFC1918/private space passes validation and is later fetched by the backend HTTP client. This enables server-side request forgery to loopback, cloud metadata, and private network targets. This issue has been resolved in version 3.16.0.

Local file inclusion (LFI) and server-side request forgery (SSRF) vulnerabilities in pgAdmin 4 LLM API configuration endpoints. User-supplied api_key_file and api_url preferences were passed to the LLM provider clients without validation. An authenticated user could read arbitrary server-side files by pointing api_key_file at any path readable by the pgAdmin process, or coerce pgAdmin into making requests to internal targets (e.g.cloud metadata services such as 169.254.169.254) by setting api_url, exploiting the chat path and model-list endpoints. Fix restricts api_key_file to the user's private storage (server mode) or home directory (desktop mode), enforces a printable-ASCII key shape and a 1024-byte read cap, and gates api_url against a configurable allow-list (config.ALLOWED_LLM_API_URLS) at every entry point. This issue affects pgAdmin 4: before 9.15.

AnythingLLM is an application that turns pieces of content into context that any LLM can use as references during chatting. Prior to version 1.12.1, GET /api/workspace/:slug/tts/:chatId in AnythingLLM returns the text-to-speech audio for another user's chat response within the same workspace because the route validates workspace membership but does not enforce ownership of the targeted chat row. As a result, an authenticated user can access another user's private assistant response in audio form if the chatId is known or guessed. This constitutes an insecure direct object reference (IDOR) affecting private chat response content exposed through the TTS endpoint. This issue has been patched in version 1.12.1.

New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. In versions 0.11.9-alpha.1 and prior, the SSRF protection introduced in v0.9.0.5 (CVE-2025-59146) and hardened in v0.9.6 (CVE-2025-62155) does not block the unspecified address 0.0.0.0. A regular (non-admin) user holding any valid API token can send a multimodal request to /v1/chat/completions, /v1/responses, or /v1/messages with 0.0.0.0 as the image/file URL host, bypassing the private-IP filter and causing the server to issue HTTP requests to localhost. This constitutes at minimum a blind SSRF; when the request is routed through an AWS/Bedrock Claude adaptor, the fetched content is inlined into the model response, upgrading it to a full-read SSRF. At time of publication, there are no publicly available patches.