Threats Tagged 'web'

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

When you incorporate data from application security scanners into your exposure management platform, you can assess the threat from formerly isolated code flaws using a broader risk context, which illuminates hidden exposures that your security and development teams can eliminate together. Key takeaways Break application security silos and obtain full code-to-runtime visibility by integrating standalone code scanner data with your exposure management platform. By contextualizing application security findings, filtering out alert noise, and automating patches, exposure management helps organizations pinpoint and fix the riskiest coding flaws to your organization. Leveraging exposure management, CISOs can transform technical application-security metrics into clear insights on business resilience that the board and the C-suite can understand, as well as enforce risk-based SLAs, and benchmark against industry peers. Securing the code that enterprise developers write, assemble, and deploy has been a perennial challenge for security teams. As a result, code containing vulnerabilities, misconfigurations, and other security weaknesses routinely gets released into many enterprises’ production systems and customer-facing applications. This happens because application security data often lives in silos within code-scanning tools, which makes it difficult to correlate with the rest of the organization’s security issues in cloud workloads, on-prem assets, operational technology (OT) systems, identity platforms, and more. When application security data exists in a vacuum, the findings can’t be properly and promptly assessed and prioritized. As a result, security teams can’t deliver patches and pull requests with the speed at which developers ship code. This disconnect is only getting wider, as developers use AI tools to further automate and accelerate the creation and release of code into their continuous integration / continuous deployment (CI/CD) software development pipelines. The following stats illustrate how AI coding tools are making application security considerably harder for cyber teams: Developers who use AI coding assistants commit code at three to four times the rate of their peers but introduce security findings at 10 times the rate. 45% of AI-generated code contains known security flaws , such as those listed in the OWASP Top 10 ranking of web application security risks. CVEs directly attributable to AI coding tools tripled month-over-month in early 2026, with March’s total alone exceeding the number of CVEs discovered in all of 2025, according to research from Georgia Tech . So, how can security teams successfully secure their application development lifecycle? Is the term “application security” destined to become an oxymoron in the age of AI? Not by a long shot. In this blog, we explain how the key to securing your entire code-to-runtime lifecycle lies in incorporating the data from your application security tools (ASTs) into your exposure management platform. By doing so, security teams gain full visibility into their application development pipeline and are able to see where it fits into their overall attack surface. They’re also able to assess code risks within a broader context that factors in isolated code issues and security issues present in the rest of the environment, such as cloud workloads, runtime systems, and identities. Leveraging this unified view of the attack surface , security teams can detect toxic combinations of risk that create organizational exposure. This in turn empowers security teams to precisely and quickly prioritize what they need to fix right away, and drastically reduce the number of vulnerabilities in production code. Here are the top 5 reasons you should integrate your application security program with your exposure management platform. 1. Visibility Picture this: A new zero-day vulnerability impacts a popular open-source library — think of the Log4Shell bug that unleashed a crisis for the millions of organizations with the ubiquitous Log4j Java-based logging utility in their environments. Your CISO calls for an all-hands on deck response, starting with an immediate, detailed assessment of all the assets that contain the vulnerable software. This sounds like a daunting, if not outright impossible task, but it’s entirely feasible to fulfill if you have an exposure management platform with a continuously updated, unified inventory of all your software libraries, code repositories, code owners, and associated security issues in a single view. With this comprehensive inventory of your application security data, you can pinpoint where developers write and deploy code, who owns it, where the code is running, and its blast radius. When you make application security part of your exposure management program, you get comprehensive and up-to-date visibility to quickly detect which assets are affected by a headline-grabbing zero-day vulnerability. 2. Agentic AST integration New agentic ASTs, such as Anthropic’s Claude Security and OpenAI’s GPT-5.5-Cyber, will dramatically accelerate discovery of new code vulnerabilities, which will logically increase the number of security issues that potentially need to be remediated. The result is an already massive backlog of application security findings will become even more unmanageable, worsening the security team’s alert fatigue. Here again, an exposure management platform that’s natively integrated with agentic ASTs puts these AI tools’ scanning data in the broader context of your entire attack surface. When you don’t address application security in isolation, you can more quickly, precisely and easily deduplicate code-security findings, investigate issues, analyze and assess risk, and orchestrate remediations and patches. In short, the integration of agentic ASTs with an exposure management platform streamlines the prioritization of application security risks, and automates and accelerates their remediation. 3. Prioritization context Static application security testing (SAST) and software composition analysis (SCA) tools can identify hundreds or thousands of high-risk code vulnerabilities, but these tools often list them with bare-bones data that gives security teams minimal context about their risk to the organization. Which vulnerable code is running in production? Which code lies in decommissioned microservices? Which code sits on an attack path leading to critical systems? Without these insights, you can’t decide which code security issues to fix first. With an exposure management platform, you can assess the criticality of code vulnerabilities and misconfigurations within comprehensive context and prioritize remediation accordingly, taking into account elements such as: Running assets in production vs. in development or test environments User identities and entitlements to understand authority and management privileges External asset accessibility to understand potential new entry points and attack pathways Business criticality about the codebase, application importance, and related compliance requirements. That way, you can determine the different risk levels of the same unauthenticated remote-code execution flaw. For example, the risk is different if the impacted code sits in a QA environment that is completely isolated from the internet, versus if the impacted code resides in your customer authentication application programming interface (API). Assessing code-security risk in this precise, granular manner makes all the difference in the often fraught relationship between developers and security pros. Instead of showing up with a laundry list of hundreds of code issues to fix, the security team can pinpoint a handful instead, explain to developers why those are truly critical, articulate their severity and business impact, and even provide pre-written pull requests to fix them. 4. Organizational exposure CISOs need to understand how code vulnerabilities contribute to the organization’s overall risk posture, so that they can then hold business lines accountable to risk-based service-level agreements (SLAs) and key performance indicator (KPI) metrics. Once application security data gets integrated into the exposure management program, CISOs can: Measure total exposure and risk contribution of code vulnerabilities Define and enforce exposure KPI targets Benchmark risk metrics against external peers Create customized exposure views based on internal reporting requirements Enable unified reporting of all exposures, including static code risks, in a single platform Integrating application security data into an exposure management platform elevates code flaws from a discreet developer issue to a board-level risk metric. The integration empowers CISOs to elevate their board presentations and C-level conversations from, say, SQL injections, to organizational resilience, financial risk, industry benchmarking, operational exposure, and business-line accountability. With these insights, the CISO can: Inform a line-of-business VP about the security and compliance posture of their team’s flagship mobile application Brief the CFO on potential compliance penalties stemming from specific unpatched vulnerabilities Show the CTO which development teams produce the safest code and consistently meet security SLAs 5. Mobilize remediation Application development teams get routinely bombarded with requests to patch and update their code to remediate vulnerabilities and other security issues. Without a single source of truth, developers can’t properly prioritize remediation workflows and security teams can’t easily track the status of bug fixes. With exposure management, security teams can effectively orchestrate and automate a unified remediation process across all assets and their exposures, coordinating remediation tasks that support multiple asset owners, functions, and business units. Exposure management helps consolidate actions and streamline workflows,

LastPass and Bitwarden users are being targeted by a phishing campaign using fake security alert emails. These emails impersonate legitimate corporate communications and direct users to fraudulent websites mimicking services like DocuSign. The phishing sites prompt users to download malicious files and may offer fake live support. LastPass confirms its systems have not been compromised and that the phishing emails do not originate from its infrastructure. Users who enter credentials on these phishing sites are advised to change their master passwords immediately and review their vaults for suspicious activity.

This blog examines the full lifecycle of a Python package, from hosting on repositories such as PyPI or custom web servers, through source and wheel distribution formats, to the final installation into virtual or system-wide Python environments.

A threat actor published a malicious version of the Jscrambler npm package containing infostealer malware. This backdoored package was downloaded nearly 1,500 times before detection. Jscrambler is a client-side web security tool, and the malicious package could compromise users who installed it. There is no explicit information about a patch or remediation in the provided data. The incident was reported by Bleeping Computer.

The Zimbra security team urged customers to patch a critical vulnerability affecting the Classic Web Client used to access the Zimbra Collaboration suite. [...]

The attackers call victims to direct them to phishing websites mirroring Microsoft Entra ID login pages. The post Okta Warns of Vishing Attacks Targeting Microsoft 365 Customers appeared first on SecurityWeek .

Microsoft has announced plans to disable Outlook Web Access (OWA) Light, the lightweight version of the Outlook Web App email client, in a future Exchange Server update. [...]

A reflected cross-site scripting (XSS) vulnerability exists in the WordPress Plugin WPZOOM Portfolio version 1.4.21 and earlier. This vulnerability allows an attacker to inject malicious scripts that are reflected off the web server, potentially impacting users who visit crafted URLs. The issue affects versions up to and including 1.4.21. No official patch or vendor advisory is provided in the available data. The severity is assessed as medium based on the potential impact of reflected XSS vulnerabilities.

KeepInMind plugin version 0.8.4.2 and earlier contains a stored cross-site scripting (XSS) vulnerability. This vulnerability allows attackers to inject malicious scripts that are stored and executed in the context of users viewing the affected plugin's interface. The issue affects WordPress 6.x environments running on Linux where this plugin is installed. No official patch or vendor advisory is provided in the data. The severity is assessed as medium based on the potential impact of stored XSS vulnerabilities.