Netizen Blog and News

The Netizen team sharing expertise, insights and useful information in cybersecurity, compliance, and software assurance.

recent posts

about

  • Why Software Supply Chain Security Cannot Stop at SBOMs

    Why Software Supply Chain Security Cannot Stop at SBOMs

    Software bills of materials have become one of the most visible controls in software supply chain security. They provide a machine-readable inventory of the libraries, packages, modules, frameworks, and other components associated with a software product. When a new vulnerability is disclosed, an SBOM can help an organization determine which applications may contain the affected component without waiting for development teams to search each codebase manually.

    That visibility has real security value. CISA describes an SBOM as a formal record of software components and their supply chain relationships, and its 2025 draft minimum elements proposed added data such as component hashes, licensing information, generation tools, and generation context. These fields can make component identification and comparison more reliable.

    An SBOM still answers a narrow question: What components are believed to be present?

    It does not prove that the components are trustworthy, that the source repository was secure, that the build environment was uncompromised, that the published artifact matches the reviewed source, or that the software will behave safely after deployment. It may identify vulnerable code, yet it may miss malicious code that has no CVE, compromised build logic, stolen maintainer credentials, poisoned development tools, or tampering that occurred after the SBOM was generated.

    Software supply chain security must extend from source creation through build, packaging, publication, deployment, and runtime. The SBOM is a valuable inventory inside that process. Treating it as the complete security control leaves the most consequential parts of the chain unverified.

    An Inventory Is Not Proof of Integrity

    An SBOM is commonly compared with an ingredient label. The comparison explains its purpose, but it can also obscure its limitations.

    An ingredient label tells a consumer what a product is supposed to contain. It does not prove that the factory was secure, that no one altered the product after inspection, or that the label matches what is inside the package. The same distinction applies to software.

    A development team can scan a source directory, container image, package manifest, lockfile, or compiled artifact and generate a detailed SBOM. The resulting document may list hundreds or thousands of dependencies. That record alone does not establish:

    • Who approved each source change
    • Whether the source repository was compromised
    • Whether a maintainer account was taken over
    • Which build system created the final artifact
    • Whether the build used the reviewed source revision
    • Whether an attacker modified the artifact after compilation
    • Whether the SBOM itself was altered
    • Whether a package executed malicious installation scripts
    • Whether undeclared code was downloaded during the build
    • Whether a dependency behaves maliciously despite having no known vulnerability

    SLSA makes this distinction explicit. Its current specification states that source scanning and vulnerability analysis cannot prove that the reviewed code is the same code that reached the user. Code can be changed after review, during compilation, in packaging, or through distribution infrastructure. SLSA uses provenance and increasingly hardened build requirements to create evidence connecting source code to a delivered binary.

    The difference is between composition and integrity.

    Composition records what a product contains. Integrity provides evidence that the product was created through an expected process and has not been altered outside that process. A complete supply chain program requires both.

    SBOM Accuracy Depends on How It Is Generated

    An SBOM is only as reliable as the process used to create it.

    Source-based generators inspect package manifests, project files, imports, lockfiles, and repository contents. They can identify declared dependencies that may never appear in the final release. They may also miss files added later by packaging scripts, compiler plugins, installation hooks, or external downloads.

    Build-time generators can observe dependencies resolved during compilation and packaging. They may still miss content fetched through custom scripts, dynamically loaded modules, embedded binaries, generated code, or components copied into the artifact outside the monitored build path.

    Binary and container scanners inspect the delivered artifact. They can find libraries and packages that were absent from the source manifest. Their results often depend on filenames, package metadata, hashes, language-specific markers, or database signatures. Stripped binaries, statically linked code, vendored source, modified forks, and embedded firmware can weaken that identification.

    Different generation methods can produce materially different inventories for the same application. Component naming can vary across package ecosystems, operating-system repositories, source repositories, containers, and commercial scanners. A library may appear under a package URL, CPE, repository name, distribution-specific package name, or internally assigned identifier. Poor normalization can cause a vulnerable component to go unmatched or create duplicate records that look like separate components.

    The SBOM may also describe the wrong lifecycle stage. A source SBOM, build SBOM, release SBOM, container SBOM, and deployed SBOM can all contain different component sets. Development tools and test libraries may appear in the repository but never reach production. Runtime plugins may be installed after the release SBOM was generated.

    Security teams need to know what the SBOM represents, which artifact it covers, which tool created it, when it was produced, and which limitations apply. CISA’s 2025 draft proposal to add generation context reflects this need. A component list without context can create a false impression of completeness.

    A Static SBOM Becomes Stale Quickly

    Modern software is not a fixed collection of files.

    Container images are rebuilt. Base images change. Packages are updated. Plugins are installed. Feature flags activate new code paths. Infrastructure definitions pull modules from registries. Applications call external services whose internal components are controlled by another organization. Serverless functions and short-lived workloads can appear and disappear between inventory scans.

    An SBOM generated during an earlier release does not necessarily represent the software running today.

    This problem is more severe in environments that use floating version ranges, mutable container tags, unpinned Git references, automatic dependency updates, or installation commands that resolve packages at deployment time. Two builds created from the same source revision can contain different transitive dependencies when resolution occurs on different dates.

    A useful SBOM program must bind each SBOM to an immutable artifact digest and track the document through the artifact lifecycle. The SBOM for a container should correspond to the exact container-image digest being deployed, not merely to the repository name or a mutable tag such as latest.

    Production inventory must also reconcile intended composition against observed deployment. A signed SBOM may accurately describe an approved release yet fail to identify an unauthorized plugin, injected library, side-loaded module, or post-deployment modification.

    SBOM generation cannot be a quarterly compliance exercise. It must occur as part of each controlled build and remain connected to deployment records, asset inventory, vulnerability intelligence, and runtime telemetry.

    Known Vulnerabilities Are Only One Supply Chain Risk

    Most SBOM consumption workflows begin by matching components against vulnerability databases. The process typically involves mapping package names and versions to CVE records, assigning severity, and creating remediation tickets.

    That workflow can identify known vulnerable dependencies. It does little against malicious packages or intentional backdoors that have no prior vulnerability record.

    A newly compromised package can retain a legitimate name, version structure, maintainer identity, and registry location. At the point of publication, no CVE may exist. A vulnerability scanner can report a clean result even though the package contains credential theft, remote-access code, or a destructive installation script.

    The XZ Utils compromise showed this gap. CISA described the incident as a multiyear effort in which a malicious actor gained maintainer trust and inserted a backdoor into versions 5.6.0 and 5.6.1. The backdoor was found through anomalous system behavior rather than ordinary dependency vulnerability scanning. An SBOM could identify the XZ version after the affected releases were known, but it could not establish that the release process had been socially compromised before disclosure.

    A malicious component does not need a coding defect. Its harmful behavior may be intentional and function exactly as its author planned. CVE-oriented workflows are built mainly to track security weaknesses, not to determine whether a trusted maintainer has become malicious or whether a package publication account has been stolen.

    Supply chain monitoring must include package reputation, maintainer changes, publication anomalies, unexpected scripts, dependency behavior, registry events, and differences between successive releases.

    The Build System Can Be Compromised Without Changing the Declared Dependencies

    An attacker does not need to poison an open-source library. Compromising the build pipeline can provide a cleaner route into the final product.

    Build environments frequently hold high-value permissions. They can access source repositories, package registries, cloud accounts, signing services, deployment platforms, container registries, and production secrets. A malicious workflow action, compiler extension, build plugin, runner image, or CI script can steal credentials or modify artifacts without adding an obvious application dependency.

    The 2025 compromise of tj-actions/changed-files demonstrated this risk. Attackers modified version tags so that workflows referencing those tags executed a malicious commit. The compromised action dumped CI/CD secrets into workflow logs and potentially affected more than 23,000 repositories. CISA reported that the incident may have been linked to the compromise of another GitHub Action.

    An application SBOM might list every library inside the final product and still miss the compromised workflow action. The action may never be shipped with the application. It exists in the build control plane, where it can access secrets and influence what gets produced.

    This creates a second supply chain inventory requirement: organizations need visibility into the tools that create software, not just the components included in it.

    That scope includes:

    • CI/CD actions and plugins
    • Compilers, linkers, and build systems
    • Runner and build-worker images
    • Package managers
    • Code generators
    • Signing services
    • Deployment tools
    • Infrastructure modules
    • Security scanners
    • Artifact repositories
    • External scripts invoked by the pipeline

    A product SBOM describes the product. It does not automatically describe the full machinery used to create that product.

    Trusted Package Names Can Hide Compromised Publishers

    Package registries create a strong association between package identity and trust. Developers often assume that a familiar package name from its normal registry is safe.

    That trust can fail when attackers obtain maintainer credentials, steal automation tokens, compromise a developer workstation, or abuse account-recovery procedures.

    GitHub reported that the September 2025 Shai-Hulud npm attack used compromised maintainer accounts to inject malicious post-install scripts into popular packages. The worm stole multiple classes of secrets and attempted to spread through the package ecosystem. GitHub removed more than 500 compromised packages and outlined plans for stronger authentication, short-lived granular tokens, FIDO-based authentication, and trusted publishing.

    An SBOM generated from an affected application could correctly record the package name and malicious version. The inventory would still provide no assurance that the publisher was authorized to release that version or that the version’s contents matched an approved source revision.

    This is why identity controls and publication controls belong inside supply chain security.

    Maintainers and vendors should reduce reliance on reusable registry tokens, require phishing-resistant authentication, use protected release environments, separate developer and publisher permissions, and prefer trusted-publishing systems based on short-lived workload identity. A package release should be attributable to a known repository, workflow, source revision, and build environment.

    Digital Signatures Help, but Signing Alone Is Not Enough

    Artifact signing can prove that an artifact was signed by a particular identity and that its contents have not changed since the signature was created. That is a major improvement over unsigned distribution.

    A valid signature does not prove that the signed artifact is safe.

    An attacker who steals a signing key can sign malicious code. A compromised CI workflow may request a legitimate signature for a poisoned build. A trusted insider may authorize a harmful release. A signing service may correctly sign whatever digest the pipeline submits, even when the pipeline has been altered.

    Sigstore addresses several weaknesses in traditional signing through short-lived identity-bound certificates and the Rekor transparency log. Its verification flow checks the artifact signature, expected signer identity, certificate chain, and proof that the signing event was recorded in the log. The result establishes who signed an artifact and whether it changed after signing.

    Those controls still need a policy that defines which identities, repositories, workflows, branches, and build systems are permitted to sign a release.

    A consumer should not ask only, “Is this artifact signed?” The stronger questions are:

    • Was it signed by the expected workload identity?
    • Did the signature originate from the approved repository?
    • Was the build triggered from a protected branch or release tag?
    • Does the provenance identify the expected source commit?
    • Was the build performed on an approved build service?
    • Is the artifact digest the same digest recorded in the SBOM and deployment manifest?
    • Does the signing event appear in the expected transparency log?
    • Was the signer identity behaving consistently with prior releases?

    Signatures become more valuable when they are connected to provenance, policy, and independent verification.

    Provenance Connects Source Code to the Final Artifact

    Build provenance records verifiable information about how an artifact was produced. Depending on the format and assurance level, it can identify the builder, build process, source repository, source revision, inputs, parameters, and output digest.

    SLSA organizes build integrity into ascending levels. Lower levels establish that provenance exists. Higher levels require stronger build-service controls and greater resistance to tampering with the build, provenance, or artifact. The current SLSA specification states that its Build Track covers Levels 1 through 3.

    Provenance helps answer questions an SBOM cannot:

    • Was this binary built from the reviewed source commit?
    • Which build platform created it?
    • Which source repository supplied the input?
    • Were unexpected build parameters used?
    • Did the artifact originate outside the approved CI system?
    • Has the artifact changed since the build completed?

    An SBOM may state that a release contains a particular library version. Provenance can show that the release came from an approved build using a defined set of inputs. The two records serve separate purposes and should be cryptographically bound to the same artifact digest.

    SLSA also states its own boundaries. It does not prove code quality, determine whether a producer is intentionally malicious, or automatically inherit assurance across every transitive dependency. Each dependency remains part of the trust analysis.

    No single attestation can cover the entire chain. Security comes from linking several types of evidence and rejecting artifacts when required evidence is absent or inconsistent.

    VEX Adds Exploitability Context

    An SBOM can create a large volume of vulnerability findings. Some represent direct, reachable exposure. Others involve code that is disabled, removed during compilation, inaccessible through the product, or used in a way that does not invoke the affected function.

    A component inventory by itself cannot make that distinction.

    Vulnerability Exploitability eXchange, or VEX, provides a machine-readable assertion about whether a product is affected by a particular vulnerability. CISA defines minimum VEX elements covering document metadata, product information, vulnerability details, and product status.

    VEX can reduce unnecessary remediation by recording why a vulnerable component is not exploitable in a particular product. It can also state that a product is affected, under investigation, or fixed.

    VEX assertions require governance. A supplier should provide technical justification, update the assertion when the product changes, and bind it to the relevant product version. Consumers should not automatically accept unsupported “not affected” claims.

    VEX is also not a substitute for runtime analysis. Reachability can depend on configuration, feature flags, network exposure, privilege, deployment architecture, and data flow. The same component may be unreachable in one deployment and exposed in another.

    A risk decision should combine the SBOM, VEX, known-exploitation data, exploit probability, code reachability, runtime exposure, business impact, and compensating controls.

    Dependency Control Must Begin Before the Build

    Generating an SBOM after dependencies have entered the environment is too late to serve as the primary admission control.

    Organizations need policies governing which packages may be introduced, where they may be retrieved, how versions are selected, and what evidence must accompany them.

    Direct public-registry access from every developer machine and CI runner gives attackers several paths into the environment. Dependency confusion, typosquatting, namespace takeover, malicious updates, and compromised publisher accounts all rely on weak controls at dependency resolution.

    A stronger model routes packages through a controlled internal repository or proxy. New components can be quarantined, scanned, and approved before broad use. Policies can block unapproved registries, newly published packages, unexpected maintainers, prohibited licenses, unsigned artifacts, and packages with dangerous installation behavior.

    Version pinning should use immutable identifiers where the ecosystem supports them. GitHub Actions should be pinned to full commit hashes rather than mutable version tags. Containers should be deployed by digest rather than tag. Downloaded tools should be verified against expected hashes and signatures.

    Pinning reduces surprise changes, but it does not prove that a pinned artifact is trustworthy. A malicious version remains malicious when pinned. Pinning must operate alongside review, provenance verification, signing, and update management.

    Securing Source Control and Maintainer Identity

    Many supply chain compromises begin before dependency resolution or compilation.

    An attacker who controls a source repository, maintainer account, or code-review process can introduce malicious changes through normal-looking development activity. The change may pass through the same build and signing systems as a legitimate release.

    Source control needs protections such as phishing-resistant multifactor authentication, protected branches, mandatory review, restricted administrative roles, signed changes where appropriate, review of workflow-file modifications, and alerts for unusual account or repository activity.

    Changes to CI workflows, release scripts, package manifests, lockfiles, ownership files, and signing configuration deserve higher scrutiny than ordinary source changes. These files define how software is built and published. A small modification can redirect dependencies, expose secrets, alter the release artifact, or transfer package ownership.

    Open-source governance also affects security. A critically used project may be maintained by one person with limited time, no backup maintainer, and no funded security support. Supplier assessments that examine only code-scanning results can miss this concentration of operational risk.

    Security review should account for maintainer continuity, release authority, account protections, governance, incident-response contacts, and the project’s ability to issue fixes.

    The Build Environment Must Be Treated as Privileged Infrastructure

    CI/CD systems often have broader access than production applications. They may hold credentials capable of publishing packages, pushing containers, signing releases, modifying cloud resources, or deploying directly into production.

    Build workers should be isolated, ephemeral, and narrowly permissioned. A build for one project should not inherit credentials or filesystem state from an unrelated project. Secrets should be issued only to the job that requires them, for the shortest possible period, and should not be exposed to untrusted pull requests or third-party actions.

    Network egress should be controlled. A build that is expected to use an internal dependency mirror should not freely download executable content from arbitrary internet hosts. Hermetic or near-hermetic builds reduce the chance that undeclared inputs can enter during compilation.

    Build logs also need protection. The tj-actions/changed-files incident showed that secrets written to logs can become exposed even when the malicious workflow does not directly transmit them to an attacker-controlled server.

    Reproducible builds provide another form of validation. When independent builds from the same source and declared inputs produce matching outputs, defenders gain evidence that the released binary corresponds to the stated build process. Reproducibility is difficult across every language and platform, but it can provide high-value verification for critical components.

    Policy Enforcement Must Occur Before Deployment

    Supply chain evidence has little effect when it is collected but never enforced.

    A deployment system should evaluate the artifact, SBOM, signature, provenance, vulnerability status, and approval records before admitting software into a sensitive environment.

    An admission policy might require:

    • An immutable artifact digest
    • A valid signature from an approved identity
    • Provenance from an approved build platform
    • A source commit from a protected repository
    • An SBOM bound to the artifact digest
    • No prohibited components or licenses
    • No unresolved vulnerabilities above the organization’s risk threshold
    • VEX justification for accepted exceptions
    • Approval for newly introduced dependencies
    • No unexplained drift from the prior release

    The policy engine should reject the artifact when evidence is missing, invalid, expired, or inconsistent. Recording a compliance warning without blocking deployment turns the control into documentation rather than prevention.

    Exceptions need owners, expiration dates, compensating controls, and review. Permanent, untracked exceptions gradually convert an enforcement system into an approval formality.

    Runtime Security Remains Necessary

    A verified build can still be exploited after deployment. A trusted supplier can still contain a vulnerability. A signed application can load unapproved plugins, contact malicious infrastructure, or expose credentials through unsafe configuration.

    Runtime controls provide containment after preventive controls fail.

    Workloads should run with limited privileges, restricted filesystem access, controlled network egress, isolated credentials, and monitored process behavior. Container admission policies can verify image signatures and provenance before deployment, yet runtime enforcement must still restrict what the container can do.

    Behavioral monitoring can identify package installation during runtime, unexpected child processes, shell execution, access to cloud metadata services, modifications to executable files, credential-store access, and outbound traffic to new destinations.

    Runtime observations can also improve vulnerability prioritization. A component known to be loaded and exposed deserves different treatment from a library present in an image but never invoked. This does not make the dormant library harmless, since configuration changes may activate it later, but it provides stronger operational context than the SBOM alone.

    Supplier Assurance Requires More Than Asking for an SBOM

    Procurement questionnaires increasingly ask vendors whether they can provide an SBOM. A “yes” answer says little about the supplier’s wider security practices.

    A meaningful supplier review should examine how the SBOM is generated, how often it is updated, whether it covers transitive dependencies, whether it is bound to specific release artifacts, and whether the supplier provides corrections when errors are found.

    The review should also ask about:

    • Secure development practices
    • Source-code protections
    • Build-environment isolation
    • Artifact signing
    • Build provenance
    • Package publication controls
    • Vulnerability disclosure
    • VEX issuance
    • Patch timelines
    • Maintainer and administrator authentication
    • Incident notification
    • Dependency approval
    • Subsupplier risk
    • End-of-life support
    • Evidence retention

    NIST’s Secure Software Development Framework provides a core set of practices that can be integrated into development lifecycles and used as a common vocabulary between producers and purchasers. NIST SP 800-161 Rev. 1 takes a broader organizational view, covering identification, assessment, and mitigation of cybersecurity risk across products, services, suppliers, and multiple organizational levels.

    The procurement objective is not to collect the largest number of documents. It is to determine whether the supplier can produce verifiable evidence that its development and delivery process is controlled.

    A Complete Evidence Chain

    A mature software supply chain program should connect several classes of evidence.

    • The SBOM records component composition.
    • The VEX document records supplier analysis of vulnerability applicability.
    • The provenance attestation records how and where the artifact was built.
    • The digital signature binds an approved identity to the artifact.
    • The transparency log provides an auditable record of signing or publication events.
    • The source-control record documents reviewed changes and approvals.
    • The deployment record identifies which exact artifact entered each environment.
    • The runtime record shows how that artifact behaved after deployment.

    Each record answers a different security question. None can safely replace the rest.

    These records should share stable identifiers, chiefly cryptographic digests. The artifact digest in the deployment manifest should match the digest in the signature, provenance, and SBOM. A mismatch should stop the release or trigger an investigation.

    This model changes supply chain security from document collection into evidence verification.

    Moving From SBOM Compliance to Supply Chain Assurance

    Organizations often begin their SBOM program by selecting a generator and attaching its output to release artifacts. That is a useful starting point, not the finished program.

    The next stage is consumption. SBOMs must enter a system that normalizes component identities, correlates vulnerabilities, tracks product versions, processes VEX statements, assigns ownership, and opens remediation workflows.

    The stage after that is verification. The organization must determine whether the SBOM corresponds to the artifact, whether the artifact came from an approved build, and whether the build came from an approved source revision.

    The final stage is enforcement. Unverified or policy-violating artifacts must be blocked from sensitive environments. Runtime controls must limit damage when a malicious or vulnerable component still passes preventive checks.

    An SBOM provides visibility into software composition. Supply chain assurance requires evidence about identity, integrity, process, authorization, and behavior.

    The distinction matters. Many of the most serious supply chain compromises do not depend on an old vulnerable library hiding inside an application. They target maintainer trust, developer accounts, build workflows, signing infrastructure, package registries, and distribution systems. A perfect component inventory cannot stop an attacker who controls the process that creates the inventory and the software it describes.

    Software supply chain security cannot stop at SBOMs for the same reason asset inventory cannot replace endpoint protection, identity security, vulnerability management, and incident response. Knowing what exists is the foundation for control. It is not the control itself.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

  • Visual Prompt Injection: How Malicious Instructions Hide in the Interface

    Visual Prompt Injection: How Malicious Instructions Hide in the Interface

    Prompt injection was first treated mainly as a text-security problem. An attacker typed a tempted to override its system rules, and tried to make the model produce restricted information or perform an unintended task. Multimodal models and computer-use agents have changed that threat model. Instructions no longer need to arrive through a chat box. They can appear inside a webpage, screenshot, product image, email banner, advertisement, document, desktop wallpaper, or graphical control.

    Visual prompt injection, commonly shortened to VPI, exploits a model’s ability to interpret written language and semantic cues found inside visual input. An instruction presented as pixels can compete with the user’s original request, redirect the agent’s reasoning, and trigger actions through connected tools. OWASP classifies prompt injection as LLM01 in its 2025 GenAI risk list and states that an injection does not need to be visible or readable to a person. It only needs to be parsed by the model. OWASP also identifies multimodal content as a distinct attack surface in which malicious instructions can be hidden in images accompanying benign text. e becomes much more serious once a model is permitted to click, type, access files, send messages, query internal databases, call APIs, or execute terminal commands. In that setting, visual prompt injection is not merely an output-manipulation technique. It can become an initial-access mechanism for agent-driven data theft, unauthorized transactions, file modification, destructive commands, and persistent workflow compromise.

    The Interface Is Now an Instruction Channel

    Traditional user interfaces were created for humans. Text, buttons, icons, dialogs, and images communicated information to a person, who then decided what to do. Computer-use agents collapse that separation. The same interface now serves as both the operating environment and a source of model input.

    A screenshot-driven agent typically receives a user objective, captures the current screen, submits the screenshot to a vision-language model, generates a plan, and issues low-level actions such as mouse clicks or keystrokes. Browser agents may also consume the Document Object Model, accessibility tree, page text, metadata, or network responses. Data collected from the interface is placed into the agent’s reasoning context alongside trusted instructions.

    This creates an instruction-data confusion problem. The model must infer whether text in an image is a fact to read, a label to identify, a warning to report, or a command to obey. That distinction is based largely on learned patterns and contextual probability rather than a strict security boundary.

    Research behind VPI-Bench describes this risk through a black-box threat model in which an attacker places malicious visual content on a page that an agent may encounter during a normal task. The attacker does not need to breach the platform, know the user’s prompt, or possess access to the model. A seller can place content on a product page, a sender can place it in an email, and a user can publish it in a message or image. The agent sees the content during routine work and may interpret the attacker’s objective as a legitimate subtask. a major change from conventional web security. The page does not need to exploit the browser, execute native code, or gain control through a memory-corruption flaw. It attempts to influence the decision-making component that already has permission to act.

    How Pixels Become Executable Intent

    A vision-language system commonly preprocesses an image by resizing, cropping, normalizing, and dividing it into regions or patches. A vision encoder converts those regions into internal representations, which are projected into a form that can interact with the language model. The model then reasons across visual and textual representations in the same inference process.

    Text printed inside an image is not necessarily treated as passive content. A capable model may recognize the characters, infer their meaning, and follow them as instructions. Research on goal hijacking through VPI found that attack success depended heavily on two capabilities: character recognition and instruction following. Models that were better at reading text from images and acting on language were also more capable of obeying injected visual commands. ck path can be represented as a sequence:

    Attacker-controlled content → rendered interface → screenshot or page extraction → visual or textual tokens → agent planning → tool call → system action

    No single stage needs to look overtly malicious. A banner can resemble a security notification. An instruction can be placed in an email signature. A product image can contain text framed as a verification requirement. A webpage can display a dialog claiming that an agent must upload a file to continue. The model may treat the visual element as an authoritative component of the workflow.

    The attacker’s main objective is goal substitution. The user may ask the agent to compare hotel prices, summarize an email, or purchase a specific item. The injected content attempts to replace or extend that task with an attacker-selected objective, such as locating a credential file, sending a message, opening an external URL, uploading a document, or initiating a payment.

    Visible Instructions Can Still Be Difficult to Detect

    A visual injection does not need to be invisible. It may work by imitating trusted interface language.

    Common forms include fake system notices, CAPTCHA instructions, cookie banners, account-verification dialogs, support messages, product warnings, compliance notices, and approval prompts. The text may use phrases such as “required validation,” “administrator instruction,” or “complete this step before continuing.” The presentation gives the instruction contextual authority.

    Semantic alignment has a major effect on attack success. VPI-Bench found that an injected objective was more likely to be adopted when it appeared related to the user’s legitimate task. An instruction asking an agent to enter account details on a shopping page may appear more plausible than an instruction asking the agent to modify a local configuration file during a news-summary task. es attackers an incentive to create context-sensitive payloads. An injection on a travel site may request passport information. A malicious email may ask the agent to forward a document. A product listing may direct the agent to an external checkout page. A fake cloud-storage dialog may request a local file upload.

    The attack gains credibility by blending into the expected workflow rather than appearing as an obvious command to disregard prior instructions.

    Instructions Hidden From the Human Viewer

    Some attacks attempt to make the injected prompt accessible to automated systems but difficult for a human to notice. The exact method depends on how the agent collects interface content.

    An agent that parses HTML may process text that the browser does not visibly render. Attackers can use zero-sized fonts, collapsed containers, negative screen coordinates, transparent elements, white text on a white background, hidden text areas, data attributes, SVG content, or dynamically constructed elements. Agents that consume raw DOM text, accessibility data, page source, or extracted content may receive instructions that are absent from the visible viewport.

    Palo Alto Networks Unit 42 reported web-based indirect prompt injection activity in the wild in March 2026. The observed pages used combinations of font-size settings, off-screen positioning, display: none, visibility: hidden, zero opacity, color camouflage, hidden text areas, HTML attributes, SVG sections, JavaScript-generated elements, and encoded content. One observed page contained 24 separate injection attempts, apparently intended to increase the chance that at least one representation reached the target agent. research documented layered obfuscation using HTML entities, Base64, URL encoding, nested encoding, multilingual commands, bidirectional Unicode controls, and syntax-breaking strings. Some prompts were assembled at runtime through JavaScript, allowing them to evade scanners that examined only the original page source. thods expose a difficult defensive tradeoff. A security product inspecting the screenshot may miss hidden DOM content. A product inspecting the DOM may see content that the user never saw. An accessibility-based agent may receive yet another representation of the page. Each representation can contain a different instruction set.

    Image-Based Prompt Injection

    Image-based prompt injection places the command directly into visual media. The instruction may be clearly printed, blended into the image, positioned within a low-attention region, or rendered with colors and font sizes selected to remain readable to the model without drawing human attention.

    Research published in March 2026 tested a black-box image-injection pipeline that used segmentation-based region selection, adaptive font sizing, and background-aware rendering. The method selected parts of natural images where text could be concealed without entirely losing machine readability. The most effective tested configuration reached an attack success rate of up to 64 percent under the study’s stealth constraints. ters for systems that automatically inspect uploaded images, advertisements, social-media posts, scanned documents, receipts, medical images, or screenshots. A user may upload an image for classification or summarization without knowing that the image contains a secondary instruction directed at the model.

    The attack can also exploit the visual hierarchy of the scene. Large headings, high-contrast text, arrows, boxed instructions, or labels placed near interactive controls may receive more model attention than surrounding content. An attacker can use layout and typography as part of the injection rather than relying solely on the wording.

    Adversarial Image Patches

    A more technical form of VPI uses optimized image patches rather than ordinary visible text. These patches are modified so that their internal features steer a vision-language model toward an attacker-selected action.

    Research on malicious image patches against multimodal operating-system agents found that a crafted patch could be included in a desktop background or shared image and then captured as part of the agent’s screenshot. The patch could redirect an agent toward a malicious website or another attacker-selected objective. The researchers also reported that some patches transferred across user requests, screen arrangements, and multiple agents. ss of attack targets the model’s visual representation rather than relying entirely on human-readable language. The image may contain patterns that appear meaningless or decorative to a person but produce model features associated with an instruction, object, or destination.

    Recent work has extended this concept into imperceptible or near-imperceptible injection. One March 2026 study combined a bounded text overlay with optimized visual perturbations intended to align the attacked image with malicious visual and textual targets. Another May 2026 paper described an image-only cross-modal attack that optimized against internal model states, seeking to influence interpretation of both the visual input and the accompanying text prompt. tacks show why OCR-based scanning alone is incomplete. OCR may identify plainly rendered commands, yet it may fail to identify model-directed visual features that do not correspond to normal human-readable text.

    Scaling-Triggered Instructions

    Most multimodal systems resize images before inference. The uploaded image may be larger than the model’s accepted resolution, so the application applies nearest-neighbor, bilinear, bicubic, or another resampling algorithm.

    Attackers can manipulate this preprocessing step. A crafted image may appear benign at its original resolution but reveal a different pattern after downscaling. The hidden prompt is produced through the interaction between selected source pixels and the target resizing algorithm.

    Trail of Bits demonstrated this technique through its Anamorpher research and open-source tool. Anamorpher creates images whose injected text becomes visible after the image is scaled by the target pipeline. This means a user reviewing the original image may see harmless content, yet the model receives a resized version containing readable instructions. attacks expose a gap between the artifact a human approves and the artifact the model processes. Security review must account for the full preprocessing chain, including resolution changes, compression, color conversion, cropping, tiling, and frame extraction.

    A preview of the original upload is not a reliable representation of the model’s final input.

    VPI Against Computer-Use Agents

    The greatest operational risk appears when the affected model has agency.

    VPI-Bench evaluated 306 scenarios across simulated shopping, travel, news, email, and messaging platforms. The test cases included objectives involving unauthorized actions, private-data exposure, or both. The study reported that tested computer-use agents reached attack success rates of up to 51 percent on some platforms, and browser-use agents reached 100 percent in some cases. System-prompt warnings offered limited protection. inction between attempted and completed attacks also matters. An agent may start a malicious workflow but fail during a later step. That is still a security event. Opening a malicious site, reading a sensitive file, beginning an upload, or drafting an unauthorized message may expose data or create a foothold without completing the attacker’s full objective.

    Email and messaging interfaces produced high susceptibility in the VPI-Bench evaluation. On email scenarios, attack-recognition rates for the tested computer-use models fell below 16 percent. The researchers linked this result partly to contextual plausibility: instructions inside an email or message naturally resemble requests that an assistant is expected to process. s in-the-wild observations show that attackers are already planting prompts aimed at database destruction, denial of service, unauthorized purchases, forced payments, and sensitive-information leakage. The report included pages instructing agents to delete databases, execute destructive system commands, make donations, purchase products, and transfer funds through external payment services. ystem Prompts Are Not a Security Boundary

    A common defense places a warning in the agent’s system prompt, such as telling it to ignore instructions found in webpages or images. This can reduce some failures, but it does not create a strict trust boundary.

    The model still receives the user objective, system rules, interface content, prior actions, tool output, and extracted text inside one reasoning process. An attacker can restate the malicious instruction, imitate trusted language, claim higher authority, connect it to the user’s task, or distribute it across several visual elements.

    OWASP states that prompt injection stems from the way model applications process instructions and data without reliable separation. It also notes that retrieval-augmented generation and fine-tuning do not fully remove the weakness. h reached a similar result. Fine-tuning and framework-level defenses lowered some attack rates, yet successful attacks remained. System-prompt defenses produced inconsistent gains and did not stop the overall attack class. instructions written in natural language are still interpreted by the same model that is being manipulated. They are policy guidance, not an isolation control.

    Building Defenses Around Trust and Execution

    A sound defense begins by treating every interface-derived artifact as untrusted. Screenshots, page text, OCR results, accessibility labels, images, advertisements, emails, documents, metadata, and tool output must carry source and trust information through the agent pipeline.

    The agent should know that text came from an attacker-controlled product listing rather than from the user. That provenance must remain attached after OCR, summarization, extraction, or transfer between agents. Removing source labels during preprocessing gives hostile content a chance to enter the reasoning context as ordinary instructions.

    A second requirement is intent binding. Before an action is executed, the system should test whether the action is supported by the user’s authenticated request. Reading an unrelated credential file is not required to compare hotel prices. Sending an email is not required to summarize an inbox. Uploading a local document is not required to review a product page.

    Recent research on provenance-aware decision auditing proposes tracing how untrusted context influences an agent’s proposed action. The ARGUS system constructs an influence graph and checks whether an action is justified by trustworthy evidence before execution. Its reported evaluation reduced attack success to 3.8 percent and retained 87.5 percent task utility in the tested settings. These results apply to that study’s benchmark and should not be treated as a universal guarantee. ict the Action Layer

    The model should not be the final authority on whether a sensitive action is permitted.

    Agent tools need narrow, predefined functions. A tool such as lookup_current_user_order is safer than an unrestricted SQL execution interface. A function that sends a message to a preapproved recipient is safer than an open-ended messaging tool. Identity and authorization filters should be applied by deterministic backend code rather than supplied as parameters chosen by the model.

    Google’s secure-agent guidance recommends treating external data as untrusted, avoiding open-ended plan-and-execute structures, restricting the model to a small set of predefined actions, blocking dynamic tool registration, and enforcing access allowlists outside the model. It also recommends a dual-model structure in which a separate guard component checks incoming content and proposed actions. ivilege limits the blast radius when interpretation fails. An agent that can read only a temporary working directory cannot exfiltrate an entire home folder. A browser session without stored payment credentials cannot complete a purchase. A database account with read-only access cannot drop a table.

    High-impact operations should require fresh user approval. The confirmation should display the exact action, target, data involved, and reason. A generic “continue?” dialog gives the user too little information to identify goal substitution.

    Inspect the Model’s Actual Visual Input

    Visual security testing must operate on the representation submitted to the model, not solely on the original file.

    The pipeline should retain and inspect post-resize images, cropped tiles, OCR output, extracted frames, rendered PDFs, accessibility trees, and DOM text. Comparing several renderings can reveal content that appears only after scaling, color conversion, or alternate parsing.

    Potential controls include OCR-based instruction detection, visual-text localization, metadata removal, image re-encoding, random resizing, patch masking, and comparisons across multiple resampling algorithms. None of these controls covers every form of VPI. Re-encoding may disrupt some perturbations but leave visible text intact. OCR may identify textual commands but miss adversarial patches. Cropping may remove a malicious border but retain an injected instruction embedded inside the subject of the image.

    The result should feed a risk score used by the orchestration layer. It should not be treated as a single pass-or-fail classifier.

    Detect Behavioral Deviation at Runtime

    Agent monitoring should focus on the difference between the user’s goal and the agent’s proposed behavior.

    Useful telemetry includes the source of each instruction-like phrase, screenshots observed before an action, OCR results, tool-call parameters, files accessed, destinations contacted, messages drafted, permission changes, and confirmation decisions. Security teams should be able to reconstruct which visual element influenced a particular action.

    Runtime rules can flag actions that introduce a new domain, external recipient, local file, credential store, payment method, shell command, or privileged API that was absent from the original request. These signals are valuable even when the prompt itself does not match a known malicious pattern.

    System-level isolation remains the final containment layer. VPI-Bench recommends permission gating, sandboxing, runtime monitoring, and stronger separation between human-initiated and agent-initiated operations. An operating system that can identify agent-generated actions can apply stricter rules to file deletion, software installation, credential access, and system configuration changes. ng Visual Prompt Injection

    Agent security assessments need test cases across every representation the agent consumes.

    Testing should include visible banners, fake dialogs, email bodies, image captions, transparent text, off-screen DOM elements, SVG instructions, dynamically generated content, multilingual prompts, encoded payloads, resized images, adversarial patches, and instructions distributed across multiple screenshots.

    Scenarios should measure more than whether the model repeats the injected text. The assessment should record whether the agent recognized the attack, attempted the malicious objective, accessed protected data, issued a tool call, completed part of the workflow, requested confirmation, or reached the final attacker-selected outcome.

    Tests also need semantic variation. A generic instruction may fail, yet the same objective may succeed after being framed as a required step in the user’s task. Early-stage and late-stage injection should both be tested. VPI-Bench found that later injections remained effective after the agent had already completed several legitimate steps. exercises should be performed inside isolated environments using synthetic credentials, files, payment records, and communication accounts. The objective is to evaluate the full sequence from exposure to execution without placing production data at risk.

    The Interface Has Become a Security Boundary

    Visual prompt injection turns interface content into a control-plane threat. Any pixel, label, image, email, banner, or rendered document encountered by an agent may contain language that competes with the user’s request.

    The weakness is rooted in a core capability of multimodal systems: they are trained to interpret meaning across text and images, then act on that meaning. The same capability that lets an agent read a form, identify a button, and follow written directions also allows hostile content to present its own directions.

    No image filter or defensive system prompt can fully resolve that conflict. Safer deployments need several independent controls: provenance tracking, intent binding, constrained tool interfaces, deterministic authorization, least privilege, visual preprocessing analysis, action confirmation, runtime detection, and sandboxing.

    The central security question is no longer limited to whether an AI agent can interpret the screen correctly. It is whether the system can prevent the screen from becoming the attacker.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

  • Microsoft July 2026 Patch Tuesday Fixes Record 570 Vulnerabilities, Including Three Zero-Days

    Microsoft July 2026 Patch Tuesday Fixes Record 570 Vulnerabilities, Including Three Zero-Days

    Microsoft’s July 2026 Patch Tuesday is the largest security release in the company’s history, delivering fixes for 570 vulnerabilities, including three zero-days. Two of the zero-days were actively exploited in the wild, while the third had been publicly disclosed before patches became available. The release also addresses 59 critical vulnerabilities, including 48 remote code execution flaws, nine elevation of privilege vulnerabilities, one security feature bypass, and one spoofing vulnerability.

    Microsoft noted that this dramatic increase in vulnerability volume is partly the result of its expanded use of AI-assisted vulnerability discovery, allowing the company to identify and remediate more flaws before they can be exploited.

    Breakdown of Vulnerabilities

    • 254 Elevation of Privilege vulnerabilities
    • 145 Remote Code Execution vulnerabilities
    • 102 Information Disclosure vulnerabilities
    • 35 Denial of Service vulnerabilities
    • 17 Security Feature Bypass vulnerabilities
    • 16 Spoofing vulnerabilities

    These totals do not include vulnerabilities patched earlier in Microsoft services such as Mariner, Azure OpenAI, Azure Synapse, Microsoft 365 Copilot, Exchange Online, Microsoft Edge for Android, and Microsoft Entra Provisioning Service. They also exclude 468 Microsoft Edge and Chromium vulnerabilities addressed separately by Google.

    Non-security updates released this month include Windows 11 KB5101650 and KB5099414, along with Windows 10 KB5099539 Extended Security Updates.

    Zero-Day Vulnerabilities

    July’s Patch Tuesday addresses three zero-day vulnerabilities, including two confirmed to be under active attack.

    CVE-2026-56155 | Active Directory Federation Services Elevation of Privilege Vulnerability

    This actively exploited vulnerability allows an authorized attacker to elevate privileges due to insufficient access control within Active Directory Federation Services. Successful exploitation grants administrative privileges, making this a particularly significant risk in enterprise identity environments. The vulnerability was discovered by Microsoft’s Detection and Response Team (DART), suggesting it was identified during an active incident response investigation.

    CVE-2026-56164 | Microsoft SharePoint Server Elevation of Privilege Vulnerability

    This actively exploited flaw allows an unauthenticated attacker to elevate privileges over the network because of missing authentication for a critical SharePoint function. Microsoft recommends enabling the Antimalware Scan Interface (AMSI) and configuring Request Body Scan mode to Full as an additional mitigation. The vulnerability was discovered by researchers from Mandiant Incident Response, Google Cloud, FLARE OTF, and an anonymous contributor.

    CVE-2026-50661 | Windows BitLocker Security Feature Bypass Vulnerability

    This publicly disclosed vulnerability allows an attacker with physical access to bypass BitLocker device encryption and gain access to encrypted data stored on the system drive. Although exploitation requires physical access, the flaw is particularly important for organizations relying on BitLocker as a primary safeguard for endpoint devices.

    Other Notable Vulnerabilities

    In addition to the zero-days, Microsoft addressed 56 other critical vulnerabilities, including dozens of remote code execution flaws affecting Windows services, enterprise infrastructure, and productivity components. The unusually large number of privilege escalation and remote code execution vulnerabilities makes this one of the most consequential Patch Tuesday releases to date.

    Adobe and Other Vendor Updates

    Several major vendors also released security updates during July 2026:

    • Adobe released updates addressing seven maximum-severity vulnerabilities in ColdFusion and Campaign, including a ColdFusion flaw later confirmed to be exploited in attacks.
    • BeyondTrust patched two critical authentication bypass vulnerabilities affecting Remote Support and Privileged Remote Access.
    • Cisco released updates for Identity Services Engine, Catalyst Center, ClamAV, and confirmed active exploitation of CVE-2026-20230, originally patched in June.
    • Fortinet addressed vulnerabilities across FortiOS, FortiSandbox, FortiPAM, FortiSASE, and FortiProxy.
    • Gitea patched a critical authentication bypass affecting its Docker image.
    • Ivanti released fixes for vulnerabilities in Ivanti Xtraction.
    • Linux kernel developers patched the Januscape vulnerability, which allows virtual machine escape and host code execution.
    • NVIDIA issued updates for Triton Inference Server and TensorRT-LLM.
    • Progress Software released fixes for a high-severity ShareFile Storage Zone Controllers path traversal vulnerability that prompted emergency shutdowns.
    • Ubiquiti patched vulnerabilities in UniFi OS, including a maximum-severity command injection flaw.
    • U-Boot maintainers released fixes for vulnerabilities affecting firmware integrity.
    • SAP released July security updates addressing four critical vulnerabilities across NetWeaver, Commerce Cloud, and AppRouter.
    • VMware issued updates for Avi Load Balancer addressing authentication bypass and remote code execution vulnerabilities.
    • Zimbra released a patch for a critical cross-site scripting vulnerability affecting the Classic Web Client.

    Recommendations for Users and Administrators

    Given the unprecedented size of this month’s release and the presence of actively exploited vulnerabilities affecting Active Directory Federation Services and SharePoint Server, organizations should treat July’s updates as a high-priority deployment. Identity infrastructure, collaboration platforms, and internet-facing systems should be patched immediately.

    Administrators running SharePoint should verify AMSI is enabled and configure Request Body Scan mode to Full where supported. Organizations relying on BitLocker should continue enforcing physical security controls alongside software updates, as physical access remains a prerequisite for exploitation of the BitLocker bypass.

    Security teams should also review updates from Cisco, Fortinet, VMware, SAP, NVIDIA, and other vendors where authentication bypass, remote code execution, and virtualization vulnerabilities could provide additional attack paths. With Microsoft now leveraging AI-assisted vulnerability discovery, organizations should expect larger Patch Tuesday releases going forward and plan testing and deployment processes accordingly.

    Full technical details and patch links are available in Microsoft’s Security Update Guide.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

  • Netizen: Monday Security Brief (7/13/2026)

    Netizen: Monday Security Brief (7/13/2026)

    Today’s Topics:

    • ATM Jackpotting Shows Why Encryption Wrappers Cannot Be Treated as a Final Defense
    • RoguePlanet Shows Why Security Tools Are Becoming Post-Compromise Targets
    • How can Netizen help?

    ATM Jackpotting Shows Why Encryption Wrappers Cannot Be Treated as a Final Defense

    ATM security often looks stronger from the outside than it is at the computing layer. The vault section is physically hardened, cash cassettes are protected, and forced entry into the lower half of the machine is difficult by design. The upper section tells a different story. That area houses the Windows system, storage, peripherals, and software stack that decide what the ATM can do.

    That split is where jackpotting risk lives. Attackers do not need to break into the cash vault if they can compromise the computer that instructs the dispenser. Modern ATM jackpotting targets the software path that sits between the operating system and the cash hardware, then abuses that path to make the machine dispense money without a legitimate banking transaction.

    A new set of reported vulnerabilities in CryptWare CryptoPro Secure Disk brings that issue back into focus. Security researcher Matt Burch of Atredis Partners reportedly found nine vulnerabilities in CryptoPro, a full-disk encryption and pre-boot authentication product used in corporate environments and linked to ATM security deployments. The impact is disputed: Burch argues the flaws can support ATM jackpotting under certain conditions, while Diebold Nixdorf says the findings pose little to no added real-world risk to its ATMs and says only two of the nine were theoretically applicable to its hard-disk encryption implementation.

    That dispute matters, but it should not distract from the larger security issue. ATM defenses often depend on layered controls: physical locks, trusted boot, disk encryption, application whitelisting, vendor security suites, hardware monitoring, and operational procedures. If the pre-boot or disk encryption layer fails open, stores key material in recoverable locations, or permits unauthorized boot paths, the rest of the stack may inherit a compromised starting point.

    In other words, encryption is useful only if its keys, boot chain, and failure modes are protected with the same rigor as the data it is meant to guard.

    ATM jackpotting is not traditional card fraud. The attacker is not stealing a customer’s PIN, cloning a card, or convincing a bank to authorize a withdrawal. The attacker is trying to control the ATM itself.

    The FBI warned in February 2026 that threat actors were deploying ATM jackpotting malware, including Ploutus family malware, to infect ATMs and force cash dispensing. The FBI reported more than 1,900 jackpotting incidents since 2020, with over 700 incidents and more than $20 million in losses occurring in 2025 alone.

    The technical target is the eXtensions for Financial Services layer, commonly referred to as XFS. XFS is the software layer that lets ATM applications communicate with hardware components such as cash dispensers. In a legitimate transaction, the ATM application receives authorization from the bank and then sends instructions through XFS. If malware can issue its own commands through that layer, it can bypass normal transaction flow and cause the dispenser to release cash.

    This is why physical access to the ATM head unit is so meaningful. If an attacker can reach storage, ports, internal cabling, or the operating system environment, the attack shifts from brute physical theft to software-driven control. The vault may remain intact, but the computer can still be manipulated into dispensing funds.

    The FBI notes that common infection methods include removing the ATM hard drive, connecting it to another computer, copying malware to it, reinstalling it, and rebooting the machine. Attackers have also replaced drives or attached external devices with preloaded malware.

    Full-disk encryption is meant to disrupt that workflow. If an attacker removes the drive, the data should remain unreadable. If the attacker attempts to alter the boot environment, secure boot and pre-boot authentication should prevent unauthorized code from gaining control. If the drive is offline, encryption should prevent malware staging, key recovery, and direct manipulation of the Windows environment.

    That is the theory. The reported CryptoPro vulnerabilities raise questions about implementation details that can weaken that theory.

    According to the Dark Reading report, some of the issues involved the way CryptoPro handled pre-boot decryption. In one reported failure mode, a decryption failure could result in volumes being mounted in plaintext. Another issue involved a weak check for disk encryption state, where an attacker could make a disk appear encrypted and cause plaintext mounting behavior. Burch also reportedly found that CryptoPro key material and configuration values were stored on disk, and that the Secure Boot setup could allow attacker-controlled Linux execution instead of the vendor’s intended environment.

    Taken together, those weaknesses describe a familiar pattern in failed cryptographic systems. The encryption algorithm may be sound, but the surrounding system exposes the key, trusts the wrong boot state, or handles errors in a way that favors availability over protection.

    For ATMs, that distinction is more than academic. A strong cipher does not help if an attacker can recover the key material. Pre-boot authentication does not help if an attacker can steer the system into a permissive fail state. Secure Boot does not help if the trusted path can be replaced or bypassed. Disk encryption does not help if the operating system can be decrypted offline and modified before the machine returns to service.

    ATM defenses depend heavily on the assumption that the system boots into a known, trusted state. That assumption has to hold before the Windows environment loads, before vendor security software starts, and before application controls inspect running processes.

    If the pre-boot environment can be altered, the attacker gets to operate at a layer below many familiar endpoint controls. Antivirus, EDR, application whitelisting, monitoring agents, and ATM application logs may all depend on the protected OS starting cleanly. A compromised boot path can undermine those controls before they have a chance to enforce policy.

    That is why these reported CryptoPro issues are significant even outside the ATM debate. The flaws point to the security gap between using encryption and validating the entire trust chain around encryption.

    Pre-boot controls should answer several questions before the protected system starts. Is the bootloader trusted? Is the disk state valid? Are keys protected outside attacker-controlled storage? Are configuration values tamper-resistant? Are fallback states safe? Can the device detect unauthorized hardware or storage changes? Can administrators prove that the system running today matches the approved baseline?

    If any of those answers are weak, encryption may become more of a compliance marker than an actual containment control.

    The impact on Diebold Nixdorf ATMs is not settled from the public information available. Diebold told Dark Reading that it does not use BitLocker or CryptoPro Secure Disk for BitLocker, and said the findings are not directly applicable. The company also acknowledged that its ATMs use some CryptoPro components in Vynamic Security HDE, and said two of the reported vulnerabilities were theoretically applicable under certain conditions. Dark Reading reported that Diebold appears to have addressed those two issues in a December 2025 update.

    That leaves two separate risk tracks.

    The first is the ATM-specific track. If an ATM implementation uses affected CryptoPro components in a way that exposes the reported failure modes, the risk could affect pre-boot integrity, disk confidentiality, and jackpotting resistance. If the implementation does not use the affected component paths, the direct ATM impact may be limited.

    The second is the enterprise endpoint track. CryptoPro is marketed beyond ATM environments, and the vendor reportedly claims more than 500,000 licenses across five continents and 20 industries. For organizations using CryptoPro to protect Windows systems, the central question is still whether encryption keys, configuration values, boot logic, and fail states are protected against local attackers.

    That broader lesson applies to any encryption wrapper, not just CryptoPro. Products that sit around BitLocker, bootloaders, pre-boot authentication, or disk unlocking routines should be reviewed as security-critical code.

    Security products often face a design tension between recoverability and protection. If decryption fails, should the product block access entirely, attempt recovery, or continue in a degraded state? In enterprise desktop support, recovery-friendly behavior may reduce downtime. In a physical-access adversary model, permissive fallback behavior can become an attack path.

    ATMs are a physical-access system. Attackers may be able to open the head unit, remove drives, attach devices, reboot the machine, or trigger abnormal boot conditions. A fail-open or fail-soft design can reward exactly the kind of tampering the product is supposed to resist.

    The safer principle is simple: when a protected volume cannot be validated or decrypted through the approved path, it should not mount in a usable plaintext state. If a boot environment cannot prove integrity, it should not continue into a trusted operating mode. If key material cannot be protected from the local attacker, the encryption layer should not be treated as a meaningful barrier.

    This is also why key storage is central. Storing sensitive key material or recoverable configuration data on the same disk being protected creates a circular dependency. The system may appear encrypted, but the secrets required to defeat that encryption may be within reach of the attacker.

    Disk encryption is one layer. ATM operators need controls that detect and limit physical tampering, unauthorized devices, storage changes, and unexpected process activity.

    The FBI recommends targeted audit policies focused on removable storage usage, controlled file access, and process creation, paired with gold image integrity validation. The FBI also states that deviations from verified baseline hashes, especially unsigned or newly introduced binaries, should be treated as potential compromise indicators.

    That guidance is practical since jackpotting malware often relies on locally introduced files that may not cross a network security control. A network sensor may never see the initial infection if the attacker installs malware directly onto the ATM drive. Host-level integrity checks, removable media logging, device control, and baseline comparison become central.

    Physical telemetry matters too. The FBI lists indicators such as ATM door open alerts outside maintenance windows, unauthorized devices connected to the ATM, hard drive removal, unexpected out-of-service conditions, and abnormal low or no-cash states.

    For financial institutions and ATM operators, these events should not live in separate silos. Physical access events, Windows logs, application logs, device-control alerts, dispenser events, and cash telemetry should be correlated. An ATM head unit opening at 2:00 a.m., followed by USB activity, unexpected file creation, and a cash-out event should be treated as a single incident path.

    The ATM angle is attention-grabbing, but the same class of vulnerabilities can matter in ordinary enterprise environments. Full-disk encryption and pre-boot authentication are common controls for laptops, kiosks, field systems, shared workstations, and regulated endpoints.

    A local attacker with device access may try to recover keys, tamper with boot logic, bypass authentication, or modify the offline operating system. In a stolen laptop scenario, the goal may be data theft. In a kiosk or workstation scenario, the goal may be persistence, credential access, or bypassing local controls. In an ATM scenario, the goal may be cash dispensing.

    The system context changes, but the cryptographic design questions remain the same.

    Where are the keys stored? Can they be recovered offline? What happens when decryption fails? Can the boot environment be replaced? Are configuration files protected against tampering? Does Secure Boot cover the full chain? Are recovery features documented and access-controlled? Can admins detect that a protected device booted from an unexpected environment?

    Organizations using third-party encryption wrappers should test those questions directly instead of assuming that full-disk encryption alone solves local compromise.

    Financial institutions, ATM deployers, and enterprises using pre-boot encryption products should start by identifying where CryptoPro or similar wrappers are deployed. That means reviewing ATM security suites, endpoint encryption tools, kiosk images, vendor packages, and licensing data rather than relying only on product names visible to end users.

    For ATM environments, teams should confirm whether hard-disk encryption components have received vendor updates released in late 2025 or later, especially if they use Diebold Vynamic Security HDE or CryptoPro-related components. The public reporting indicates that Diebold quietly addressed two theoretically applicable issues in December 2025, but operators need confirmation from their own vendor channels.

    Operators should verify gold images and baseline hashes for ATM software stacks, including executables, DLLs, services, configuration files, boot components, and security agents. Any mismatch should be reviewed as potential tampering, not routine drift.

    Device-control policies should block unauthorized USB storage, external drives, keyboards, hubs, and remote access tools. The FBI’s listed indicators include unexpected remote connection applications such as TeamViewer or AnyDesk, abnormal autoruns, custom services, nonstandard service paths, and unexpected executables on Windows-based ATMs.

    Incident response teams should also collect physical telemetry. Door-open alerts, camera footage, maintenance schedules, cash-level events, out-of-service states, storage removal, and USB insertion logs can place malware activity in the right operational context.

    For enterprise Windows fleets, security teams should review pre-boot encryption architecture as part of endpoint assurance. The review should include local attacker testing, key recovery analysis, Secure Boot validation, tamper detection, recovery workflow review, and fail-state testing.

    RoguePlanet Shows Why Security Tools Are Becoming Post-Compromise Targets

    RoguePlanet is a reminder that endpoint security software is part of the attack surface it is meant to defend. The vulnerability, tracked as CVE-2026-50656, affects the Microsoft Malware Protection Engine used by Microsoft Defender and can allow a low-privileged local attacker to gain SYSTEM-level privileges on a Windows host. Microsoft assigned the issue a 7.8 CVSS score, and NVD maps the weakness to CWE-59, improper link resolution before file access.

    The timing makes the issue more serious than a routine local privilege escalation bug. RoguePlanet was publicly disclosed with proof-of-concept exploit material before a fix was available, placing defenders in the difficult position of managing exposure to a known technique affecting one of the most widely deployed security components in Windows environments. Microsoft later remediated the issue in Microsoft Malware Protection Engine version 1.1.26060.3008, with Qualys also advising organizations to upgrade to that engine version to address the vulnerability.

    RoguePlanet does not provide initial access by itself. An attacker already needs the ability to run code locally, whether through a compromised standard user account, malware execution, a phishing payload, a malicious document, browser compromise, or another foothold. That limitation matters, but it should not lead security teams to understate the risk. Local privilege escalation is often the point where an intrusion changes from a contained endpoint event into a full host compromise.

    On a Windows system, SYSTEM-level execution is a major threshold. It can give an attacker the ability to disable security controls, access protected areas of the operating system, dump credentials, install persistence, manipulate logs, stage payloads, and prepare for lateral movement. Kudelski Security describes RoguePlanet as a local elevation-of-privilege vulnerability that can allow an attacker with local access to spawn a SYSTEM command shell on a fully patched Windows host. The same advisory notes that the public proof of concept was reported to work whether Defender real-time protection was enabled or disabled.

    That detail is what makes the Defender angle so uncomfortable. Security tools are commonly treated as a defensive constant in endpoint strategy. Organizations expect them to block malware, inspect files, generate telemetry, and contain suspicious behavior. RoguePlanet flips that trust relationship. The engine responsible for scanning and remediation becomes the component an attacker can abuse to gain control.

    The underlying weakness class helps explain the risk. NVD lists CWE-59, improper link resolution before file access, for CVE-2026-50656. In practical terms, that class of bug involves software acting on a file path or link in a way that can be redirected or manipulated before the privileged operation occurs. In a security engine running with elevated privileges, that kind of path-handling mistake can become dangerous. The attacker does not need the security product to ignore malware. They need the product to perform a privileged action on the wrong object at the wrong time.

    Public reporting and security advisories describe RoguePlanet as race-condition based. That places the exploit in a category where timing and filesystem behavior matter. Race conditions can be inconsistent across machines, builds, configurations, or workloads, but inconsistency does not make them harmless. Attackers can automate repeated attempts, tune for target environments, and use the exploit as a second-stage tool after gaining a foothold.

    For defenders, the operational concern is not whether RoguePlanet is remotely exploitable. It is how valuable the vulnerability becomes after an attacker lands on a host. Modern intrusions often begin with a low-privileged foothold. From there, the attacker looks for a path to higher privileges, credential access, persistence, and security-control tampering. A working Defender privilege escalation bug fits neatly into that sequence.

    That post-compromise role is especially relevant in enterprise networks where Microsoft Defender is deeply integrated into endpoint protection, telemetry, and response workflows. If attackers can gain SYSTEM by abusing the security stack, they may have a path to interfere with the same tooling defenders rely on to detect them. Kudelski Security warned that successful exploitation can support defense evasion, credential theft, lateral movement, persistence, and tampering with detection infrastructure.

    The public disclosure context also changes the urgency. RoguePlanet followed a sequence of Defender-related flaws publicly disclosed by the researcher known as Chaotic Eclipse or Nightmare-Eclipse, including BlueHammer, UnDefend, and RedSun. The Hacker News reported that RoguePlanet was the fourth Defender vulnerability disclosed by the researcher and that the earlier flaws have since been patched by Microsoft.

    That pattern matters for vulnerability management. A single local privilege escalation issue can be triaged through normal patching channels if no exploit is public and no threat activity is visible. A publicly documented issue with working proof-of-concept material belongs in a different queue, especially when it affects a security component deployed across Windows fleets. NVD’s change history also shows CISA-ADP metadata marking exploitation as “poc” and technical impact as “total,” which reinforces the need to treat the public exploit path as operationally relevant even where confirmed in-the-wild abuse remains unclear.

    The exploitation-status picture is not perfectly settled from public sources. Microsoft’s public CVE record and NVD entry establish the vulnerability, affected product, weakness mapping, and CVSS data, but public confirmation of real-world exploitation is harder to pin down. Qualys described the issue as a Defender zero-day vulnerability and said successful exploitation may allow SYSTEM-level access, then updated its guidance after Microsoft released the patch. The absence of broad public incident detail should not be interpreted as proof that exploitation has not occurred. Local privilege escalation inside endpoint security tooling is exactly the kind of technique attackers may use quietly and preserve for as long as possible.

    The fix path is comparatively direct. Microsoft remediated the vulnerability in Microsoft Malware Protection Engine version 1.1.26060.3008. The Hacker News reported that Microsoft’s update also included defense-in-depth changes to harden unspecified security-related features, and Microsoft said default enterprise and consumer configurations normally keep the Malware Protection Engine and definitions updated automatically. That does not remove the need for verification. Security teams should confirm engine version across managed Windows endpoints rather than assuming every device has already received the update.

    This is especially true for environments with update delays, disconnected systems, tightly controlled maintenance policies, virtual desktop pools, lab networks, gold images, kiosk devices, or systems using nonstandard Defender configurations. A fleet may look patched at the operating-system level but still have stale Defender engine versions. RoguePlanet sits in the Malware Protection Engine, so endpoint validation needs to check the engine itself.

    Mitigation also cannot stop at patching. Since RoguePlanet requires local code execution first, reducing initial execution paths remains key. Application control, script restriction, macro hardening, browser isolation, attachment controls, least-privilege user accounts, and phishing-resistant authentication all reduce the chance that an attacker reaches the starting point needed to abuse the vulnerability. Once a foothold exists, privilege escalation becomes a race between attacker action and defender containment.

    Detection should focus on behavior around privilege transitions and Defender tampering. Security teams should watch for unusual standard-user processes spawning SYSTEM-level shells, unexpected process trees involving Defender components, Defender service changes, configuration changes, exclusion modifications, security log gaps, scheduled task creation, new services, suspicious autoruns, credential-access tooling, and sudden changes in endpoint telemetry. SOCRadar’s guidance, as reported by Dark Reading, called out monitoring for user-context processes spawning SYSTEM shells, Defender service or configuration changes, and creation of new services, scheduled tasks, and autoruns.

    The larger lesson is that security products need to be modeled as privileged software, not invisible infrastructure. Endpoint agents, scanners, EDR components, backup tools, patching tools, remote management agents, and antimalware engines often run with elevated privileges and deep access to the host. That makes them high-value targets after initial compromise. Attackers understand that the fastest path to persistence or evasion may be through the tools installed to stop them.

    RoguePlanet also shows why defense-in-depth cannot depend on one endpoint product. Microsoft Defender may be central to a Windows security program, but host hardening, identity controls, application allowlisting, EDR telemetry, attack surface reduction rules, patch validation, privileged access management, network segmentation, and log correlation all need to share the burden. If one control becomes the target, the rest of the stack should still limit impact.

    For security teams, the practical response is clear: verify Microsoft Malware Protection Engine version 1.1.26060.3008 or later, prioritize systems that process untrusted content or have broad internal access, review Defender update health across the fleet, hunt for privilege escalation and Defender tampering behavior, and treat public security-tool exploits as urgent even when they require local access.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

  • Remote MCP Servers Are Turning OAuth Into an AI Agent Security Boundary

    Remote MCP Servers Are Turning OAuth Into an AI Agent Security Boundary

    As AI agents move from chat interfaces into production systems, the security question is no longer limited to what a model can say. It is now also about what the agent can reach, what tools it can invoke, and which user-linked accounts sit behind those tool calls.

    That shift is what makes the Model Context Protocol, or MCP, so security-relevant. MCP has become a common way for AI clients to connect to external tools, databases, SaaS platforms, cloud resources, and enterprise services. In local deployments, that connection may stay inside a user-controlled environment. In remote deployments, MCP becomes a network-exposed service boundary, often sitting between an AI agent and sensitive business systems.

    A recent paper, “A First Measurement Study on Authentication Security in Real-World Remote MCP Servers,” examined this exact layer. The researchers identified 7,973 live remote MCP servers and found that 40.55% exposed tool interfaces with no authentication at all. Among authenticated servers, 2,428 used OAuth-based authorization and 2,312 relied on static tokens or API keys. The paper then tested 119 OAuth-enabled MCP servers and found at least one confirmed authentication flaw in every server evaluated, with 325 confirmed flaws in total. The researchers also obtained 9 CVE IDs through responsible disclosure.

    MCP Has Moved From Local Tooling to Remote Authorization

    MCP was introduced as an open standard for connecting LLM-based applications to external tools and data sources. Its architecture includes hosts, clients, and servers. The host is the user-facing AI application, the client handles communication inside that host, and the server exposes tools, resources, or prompts over a defined protocol. MCP supports local standard I/O deployments and network-accessible HTTP-based deployments.

    That deployment difference matters. A local MCP server may run on the same system as the AI client, often under the same user context. A remote MCP server is closer to a conventional web service. It receives network traffic, exposes callable capabilities, and may connect into SaaS applications, ticketing systems, code repositories, CRM records, databases, cloud APIs, and other high-value resources.

    The paper’s findings show that many deployments have not fully absorbed that change in threat model. The researchers found 3,233 live remote MCP servers with no authentication. In one anonymized case, an unauthenticated MCP server exposed CRM data containing more than 5,000 internal enterprise records, including names, email addresses, phone numbers, and physical addresses.

    For defenders, the lesson is direct: an MCP endpoint is not just an AI feature. It is an access path. If it exposes tools that can query, modify, retrieve, or trigger business data, it needs the same level of authentication, authorization, logging, and exposure management applied to any externally reachable production API.

    Why OAuth Becomes Riskier in Remote MCP

    OAuth is meant to support delegated access. A user authorizes a client, an authorization server issues tokens, and a protected resource accepts those tokens. In remote MCP, this pattern becomes more complex.

    The MCP client may be a desktop app, IDE, command-line tool, browser-based client, or cloud agent frontend. Many of these are public clients that cannot safely store a long-term secret. The MCP server may then act as a protected resource for the MCP client, and at the same time act as an OAuth client to another upstream service such as GitHub, Slack, Notion, or a database platform. This creates a multi-hop authorization chain with more places for state, identity, redirect handling, and token binding to break.

    The current MCP authorization draft reflects this risk by treating a protected MCP server as an OAuth 2.1 resource server, requiring protected resource metadata, requiring access-token validation, and stating that clients must obtain a client ID through client ID metadata documents, pre-registration, or dynamic client registration. The draft also says dynamic client registration is deprecated and retained for backward compatibility in the draft version.

    The paper shows why that matters in practice. Dynamic client registration, or DCR, is convenient for MCP, since the ecosystem contains many different clients and deployment models. RFC 7591 defines DCR as a way for clients to programmatically register metadata with an authorization server and receive a client identifier. Yet in MCP deployments, an overly permissive registration endpoint can become an attacker-controlled routing primitive.

    If an authorization server accepts arbitrary callback destinations during registration, an attacker may register a malicious client, receive a legitimate client ID, and craft an authorization URL that sends the victim’s authorization code to attacker-controlled infrastructure. The paper found malicious DCR binding in 114 of the 119 tested servers, or 95.8%.

    The Core Authentication Failures Identified in the Paper

    The researchers organized the MCP OAuth findings into four categories: dynamic client registration flaws, delegated authorization flaws, open client environment flaws, and common OAuth misconfigurations. Across those categories, they identified nine concrete flaw types.

    The first major category involved DCR. Malicious DCR binding occurs when a registration endpoint accepts attacker-supplied callback destinations without strong boundary checks. Blind client trust occurs when an authorization server accepts a supplied client ID without verifying that it was actually registered. Both flaws weaken the association between a client identity and its permitted callback destination.

    The second category involved delegated authorization. Layer inconsistency occurs when the first MCP authorization layer enforces PKCE, but the upstream OAuth layer does not. Nested context pollution occurs when an MCP server places downstream routing context inside a client-visible state value, then accepts altered routing data without integrity protection or allowlist validation.

    The third category involved open client environments. PKCE downgrade occurs when an authorization server accepts requests that omit the code challenge or accept the weaker plain method. PKCE exists to protect public clients from authorization-code interception attacks by binding the authorization request to a later token exchange through a verifier and challenge. RFC 7636 states that S256 or another cryptographically secure challenge method is required to mitigate stronger interception scenarios.

    The fourth category involved traditional OAuth mistakes that become more damaging in the MCP setting. These include open redirect behavior, weak or predictable state values, and authorization code replay. On their own, these are known OAuth problems. In an MCP flow, they can combine with DCR, public-client assumptions, delegated service access, and agent tool execution.

    PKCE Downgrade Is Especially Dangerous for Agent Tooling

    PKCE is one of the main controls protecting OAuth flows for public clients. The client creates a verifier, sends a derived challenge during authorization, then presents the original verifier during token exchange. If an attacker steals the authorization code but lacks the verifier, the token exchange should fail.

    That protection collapses when the authorization server accepts authorization requests with no challenge or accepts a downgrade to the plain method. In the paper’s tested dataset, 81 of 119 servers, or 68.1%, had confirmed PKCE downgrade flaws.

    This is a high-impact finding for agent deployments. An attacker who can redirect an authorization code to an attacker-controlled endpoint may be blocked if PKCE is enforced correctly. If PKCE can be stripped or downgraded, the code itself may become enough to obtain a token. In an MCP environment, that token can represent access to agent tools, linked SaaS resources, project data, documents, tickets, repositories, or other connected systems.

    The paper’s third case study showed this exact composition: an MCP server exposed both an open redirect and weak PKCE enforcement. The attacker removed the PKCE parameters, changed the callback destination, caused the victim to authorize the request, and exchanged the resulting authorization code for a token. The researchers reported the issue and obtained CVE-2025-69898.

    Consent Pages Are Part of the Security Boundary

    The paper also calls out consent-page bypass, which was confirmed in 72 of 119 tested servers. In these cases, the authorization flow failed to show the user enough information about the final callback destination.

    This matters for MCP since many clients use localhost callbacks or custom URI schemes. A user may see a familiar MCP authorization screen and assume the flow is safe, even when the authorization result is being routed to a malicious local port or attacker-controlled callback path. If the interface hides the callback destination, the user has no clear way to spot that the approval flow has been altered.

    Consent is not just a UX feature in this context. It is part of the authorization defense model. A secure flow should show the exact callback destination, warn on localhost-only callbacks, and make client identity clear enough that users are not approving a spoofed or attacker-registered client.

    Delegated Authorization Creates Multi-Hop Failure Modes

    Remote MCP servers often act as both a resource server and an OAuth client. The MCP client authenticates to the MCP server, then the MCP server authenticates to an upstream service. This pattern was present in 81 of the 119 tested OAuth-enabled servers. Among those delegated deployments, 40 used nested state parameters to carry routing context across authorization layers.

    That creates a subtle but serious problem. OAuth state values are commonly used to bind a request to a callback and prevent cross-site request forgery. In delegated MCP flows, state may also carry routing information across layers. If that routing information is stored client-side without integrity protection, an attacker may alter it.

    The paper’s nested context pollution case study describes an MCP server that placed downstream routing data inside state. The attacker decoded the state value, changed the nested callback destination to an attacker-controlled domain, and sent the forged authorization request to the victim. After the upstream authorization flow completed, the MCP server trusted the altered nested value and forwarded authorization credentials to the attacker.

    For enterprise deployments, this is the type of issue that can be missed by normal OAuth testing. The first authorization layer may appear sound. The upstream identity provider may also behave correctly. The failure occurs in the glue logic that connects both layers.

    Unauthenticated MCP Servers Are an Exposure Management Problem

    The most direct finding in the paper is also the easiest to grasp: thousands of remote MCP servers were live on the public internet, and more than 40% of validated servers exposed tools without authentication.

    Some of those servers may be demos, tests, or intentionally public services. That does not make the pattern safe. MCP tools often abstract sensitive backend actions behind simple callable methods. A server may expose a tool named in harmless language, yet that tool may query CRM data, read project documents, enumerate tickets, trigger workflows, or access logs.

    This creates an exposure management problem for security teams. MCP endpoints should be inventoried alongside APIs, admin panels, remote management interfaces, and SaaS integrations. Security teams should know which MCP servers exist, where they are reachable from, which tools they expose, which identities they run under, and what downstream systems they can access.

    What Security Teams Should Do Now

    Organizations adopting MCP should treat remote MCP authentication as production security infrastructure, not developer plumbing.

    The first step is asset discovery. Identify all MCP servers across development, staging, and production. Confirm which ones are publicly reachable, which use HTTP-based transports, and which expose tools tied to sensitive systems. Any unauthenticated remote MCP server should be treated as a potential external exposure until proven low impact.

    The second step is OAuth flow review. Security teams should test whether the authorization server strictly validates callback destinations, rejects arbitrary DCR submissions, blocks unregistered client IDs, requires PKCE with S256, rejects authorization-code reuse, and displays meaningful consent details to users.

    The third step is delegated-flow review. Any MCP server that brokers access to an upstream service should keep routing state server-side or protect it with integrity checks. Client-visible state should be opaque from the attacker’s perspective. The MCP layer and upstream layer should enforce consistent PKCE, state, redirect, and audience checks.

    The fourth step is token and audience validation. The current MCP authorization draft requires MCP servers to validate that access tokens were issued for the MCP server as the intended audience, and states that clients must not send tokens to MCP servers other than tokens issued by that server’s authorization server. That control is necessary in agent ecosystems where a single client may interact with multiple tools, services, and authorization servers.

    The fifth step is logging and detection. MCP authorization flows should produce security telemetry for registration attempts, callback mismatches, PKCE failures, weak state values, token exchange failures, unexpected localhost callbacks, and repeated authorization-code redemption attempts. These events should feed into the same monitoring stack used for web authentication and API abuse.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

  • AI Agent Security Needs to Move to the Tool-Call Boundary

    AI Agent Security Needs to Move to the Tool-Call Boundary

    AI agents are becoming useful for the same reason they are becoming risky: they can act. They can browse websites, read files, call APIs, search repositories, invoke MCP servers, use skill files, modify documents, and trigger workflows across external systems. That makes them very different from older chatbot deployments, where most risk stayed inside the response text.

    Once an agent can take action, prompt injection stops being a model-output problem and becomes an execution-control problem. A malicious instruction hidden in a webpage, document, tool result, MCP response, or skill file can influence what the agent does next. The attacker does not need to control the user’s prompt. The attacker only needs to control something the agent reads.

    That is the structural weakness behind indirect prompt injection. Tool-augmented agents often append tool outputs directly into the conversation history as observations, then ask the model to reason over that expanded context. If the returned content contains hostile instructions, the model may treat those instructions as part of the task. The ClawGuard research frames this as a tool-call boundary problem: each proposed action needs to be checked before it reaches the real environment.

    That framing is valuable for enterprise security teams. It moves the focus away from hoping the model refuses the wrong instruction and places the control where damage actually occurs: before a file is read, before data is sent, before a command runs, before an external endpoint receives traffic, and before a tool invocation changes state.

    Alignment Alone Is Too Soft for Agentic Workflows

    Model alignment can reduce obvious misuse, but it is a weak primary control for tool-connected agents. The model is interpreting a mixed stream of user intent, system guidance, retrieved content, tool returns, and prior observations. That context is messy by design. Agents are built to absorb external information and act on it.

    This creates a recurring problem: the model must distinguish data from instruction in situations where both are represented as natural language. A webpage can contain a legitimate paragraph and a hidden command. A document can contain business content and an adversarial instruction. An MCP server can return useful tool output mixed with manipulation. A skill file can contain both valid operational guidance and attacker-controlled behavior.

    OWASP describes prompt injection as crafted input that changes model behavior in unintended ways, including inputs that may not be visible to humans but are still parsed by the model. OWASP also calls out indirect prompt injection through external sources such as websites and files, with possible outcomes that include sensitive data disclosure, unauthorized access, arbitrary command execution, and manipulated decision-making.

    That maps cleanly to agent risk. The prompt is no longer just what the user typed. The prompt is the agent’s full working context, including anything its tools return. If a security control only asks whether the model “should” obey the injected instruction, it is arriving too late and relying on a probabilistic judgment.

    A safer design asks a different question: is the next tool call allowed under the user’s original task?

    The Tool-Call Boundary Is Where Intent Becomes Action

    The tool-call boundary is the point where the agent moves from reasoning to doing. Before that point, the model may be reading, planning, summarizing, or selecting a next step. After that point, the system may access a local file, contact a domain, execute code, send data, install a package, write a record, or trigger an external service.

    That boundary is easier to govern than the model’s full internal reasoning. Security teams do not need to solve every ambiguity in natural language to block a bad action. They need to evaluate concrete attributes of a proposed tool call: tool name, command string, file path, target domain, request payload, credential material, write destination, and expected data movement.

    This is the idea behind a runtime guard for agent activity. Instead of trusting every proposed action, the system places an enforcement layer between the model and the environment. The layer checks whether the action fits the active policy. If it clearly fits, it proceeds. If it violates policy, it is blocked. If it is ambiguous, it can be queued for explicit approval and logged.

    This approach changes the security model. A malicious webpage may still persuade the model to propose a dangerous command. The command still fails if the runtime policy blocks shell execution, credential file access, unapproved outbound domains, or destructive operations.

    The agent may be manipulable at the reasoning layer, but its actions become constrained at the execution layer.

    The Three Injection Paths Security Teams Need to Watch

    The same pattern appears across three major agent attack surfaces: external content, MCP servers, and skill files.

    External content injection is the most familiar. An agent retrieves a webpage, search result, PDF, internal document, or local file. The content includes hidden or direct instructions telling the model to ignore prior guidance, extract data, call another tool, or send information elsewhere. Since the content arrives as a tool result, the agent may process it as trusted context.

    MCP server injection expands that risk into the agent integration layer. MCP servers expose tools and return structured responses, but a malicious or compromised server can embed instructions in returned content. It can also poison tool metadata before the first tool call, steering tool selection or parameter use from inside the client’s discovery process. The official MCP security guidance lists attack areas such as confused deputy patterns, token passthrough, SSRF, local server compromise, OAuth validation issues, and scope minimization concerns, which shows how broad the MCP trust boundary has become.

    Skill file injection is different but just as dangerous. Skills are reusable capability modules that may include behavioral guidance, scripts, tool instructions, and configuration. Since skills are meant to tell the agent how to behave, malicious additions can blend into legitimate guidance. A poisoned skill does not have to look like an obvious attack. It can quietly redirect behavior inside a capability the user meant to enable.

    These paths share the same core issue. The agent absorbs untrusted content into its working context, then proposes actions based on that context. A runtime defense has to assume that some observations are hostile and still keep tool execution inside the user’s intended scope.

    Task Scope Should Be Defined Before the Agent Reads the Outside World

    One of the strongest ideas in the ClawGuard design is pre-session rule creation. Before any external tool is invoked, the agent derives a rule set from the user’s stated objective. That timing matters. The user’s original task is still clean. The agent has not yet retrieved a poisoned webpage, loaded a malicious server response, or parsed a contaminated skill file.

    A task such as “summarize the latest posts from this site and save the result in this folder” has a fairly narrow security shape. It may need web access to one domain, read access to returned content, and write access to one report path. It does not need access to SSH keys, browser profiles, cloud credential files, package installation, shell pipelines, private network ranges, paste sites, tunneling services, or unlisted external domains.

    A runtime policy can capture that distinction. The baseline rules deny known dangerous categories such as credential stores, irreversible filesystem operations, reverse shells, privilege changes, agent self-modification, suspicious exfiltration endpoints, and obfuscated command patterns. Task-specific rules then add the narrow set of domains, paths, and tools required for the user’s request. In the ClawGuard design, task-specific entries cannot override fixed safety rules.

    This is closer to least privilege than ordinary agent approval prompts. The agent does not receive broad authority and then rely on the user to catch abuse. It receives a scoped operating envelope before untrusted content reaches the model.

    Blocking the Action Is Better Than Parsing Every Injection

    Indirect prompt injection is hard to detect at the content layer. Attackers can use obfuscation, paraphrasing, multi-step instruction splitting, encoding, roleplay, hidden text, formatting tricks, or context-dependent wording. Some payloads are obvious, such as “ignore previous instructions.” Others may be embedded inside normal-looking task guidance.

    Trying to classify every tool result as safe or unsafe becomes brittle. A long webpage, skill file, or MCP response may contain thousands of tokens. The hostile instruction may be subtle. The model may assemble the unsafe behavior across multiple steps.

    The action boundary offers a cleaner point of control. A security layer does not need to fully understand why the model wants to run a command like reading a private key and sending it to an external domain. It only needs to see that the proposed action violates policy.

    The ClawGuard case study uses that exact pattern. A legitimate web-summary task retrieves a page containing injected commands to read an SSH private key, exfiltrate it through curl, and remove the SSH directory. The runtime check blocks the resulting exec call, rejects the credential file path, logs the denial, and still lets the legitimate report write proceed.

    That is the practical value of boundary enforcement. It does not require perfect model judgment. It limits the model’s ability to turn hostile context into real-world effects.

    Sanitization Reduces What the Model Can Carry Forward

    Runtime authorization controls whether an action can execute, but agents also need data hygiene. Sensitive values can leak through tool arguments, tool returns, conversation memory, logs, generated content, and follow-on requests.

    A content sanitizer can reduce that risk by redacting high-value secrets before they move through the agent pipeline. That includes cloud credentials, version control tokens, CI/CD tokens, Slack tokens, webhook URLs, JWTs, bearer tokens, payment keys, SSH material, database URLs, Redis URLs, passwords, and generic API keys. The ClawGuard paper lists a default pattern library covering many of these categories.

    This type of control is not a complete data-loss-prevention program, but it gives agent systems a practical starting point. If a tool return includes a credential, the agent should not blindly append it into future reasoning. If a proposed tool call includes a secret in an outbound payload, the runtime should redact or block it before execution.

    The goal is to break the chain between accidental exposure and automatic reuse. Agents tend to carry context forward. Sanitization stops sensitive content from becoming reusable context for later tool calls.

    Skills Need Inspection Before First Use

    Skill files create a different control problem. They are supposed to be directive, so the presence of instructions is not suspicious by itself. A useful skill might tell the agent how to search repositories, format reports, generate code, or interact with a service. A malicious skill can hide inside that same structure.

    That is why skill inspection should happen before first execution. The system should analyze the skill’s content, scripts, tool dependencies, file access, network behavior, and stated purpose. Then the user or operator should confirm whether the skill belongs in the environment. If the skill changes later, it should be treated as a new artifact and inspected again.

    This is analogous to reviewing a browser extension, CI/CD plugin, or automation script. A skill is not just text. It is an instruction package that changes how the agent behaves. In a mature enterprise deployment, skills need ownership, versioning, approval, and removal paths.

    Unmanaged skill ecosystems create a supply chain issue for agents. A team may trust the agent platform but overlook the public skill repository feeding it behavior.

    Results Point to a Clear Pattern, Not a Silver Bullet

    The ClawGuard evaluation is useful since it tests runtime enforcement across multiple benchmarks and model backbones. Across AgentDojo, SkillInject, and MCPSafeBench, the basic-rule configuration reduced attack success compared with unprotected baselines. On AgentDojo, attack success reached 0% across the tested models. On MCPSafeBench, baseline attack success ranged from 36.5% to 46.1%, and the basic-rule configuration reduced it to roughly 7.1% to 11.0% across the evaluated models.

    The limitations matter too. The evaluation notes that the tested configuration used baseline rules without the full task-specific rule-induction component, and residual failures remained in cases involving content-misleading attacks or gaps in endpoint coverage.

    That makes the lesson stronger, not weaker. Runtime enforcement works best as a layered control, not a magic filter. Baseline deny rules catch high-severity patterns. Task-specific policy narrows the allowed environment. Sanitization limits sensitive data movement. Skill inspection reduces supply chain risk. User approval handles ambiguous cases. Audit logging gives defenders visibility.

    The point is not that one framework solves agent security. The point is that tool-connected agents need enforceable runtime policy, and the tool-call boundary is one of the most defensible places to apply it.

    What This Means for Enterprise AI Programs

    Organizations adopting AI agents should avoid treating prompt injection as a purely model-side issue. The security program needs to account for the systems the agent can reach and the actions it can perform.

    The first step is inventory. Security teams should know which agent platforms are in use, which tools are enabled, which MCP servers are connected, which skill files are loaded, which users can install new capabilities, which credentials the agent can access, and which external domains it can contact.

    The next step is scoping. Each agent workflow should have a defined task envelope. A support-ticket summarizer, code-review assistant, vulnerability enrichment agent, finance workflow, and cloud operations agent do not need the same file access, network access, command access, or SaaS permissions.

    After that, teams need runtime controls. High-risk actions should be denied or queued by policy, not left to model preference. Examples include shell execution, package installation, access to credential stores, writes outside approved directories, calls to unknown domains, private network access, URL shorteners, paste sites, tunneling services, destructive filesystem commands, and agent configuration changes.

    Monitoring needs to follow the same model. Agent telemetry should show tool calls, file paths, network destinations, blocked actions, user approvals, skill loads, MCP server changes, and sanitizer events. Without those records, an incident involving an agent can collapse into guesswork.

    The Security Model Has to Assume the Agent Will Be Misled

    The safest assumption is that any tool-connected agent will eventually read hostile content. It may come from a webpage, repository, email, PDF, ticket, chat thread, MCP server, database field, or skill file. Security controls should be built around that assumption.

    If an agent is misled but cannot access credential stores, cannot contact unapproved domains, cannot run shell commands, cannot install packages, cannot modify its own configuration, and cannot write outside approved paths, the impact is limited. If the same agent has broad local access, broad network access, and weak approval prompts, indirect prompt injection becomes a path to data loss or execution.

    This is the real shift in AI security. The model is no longer just generating answers. It is selecting actions inside a connected environment. That means the control plane has to move closer to the action.

    Runtime enforcement at the tool-call boundary gives defenders a concrete place to apply least privilege, content sanitization, approval, and audit logging. It does not remove the need for safer models, better prompts, or stronger MCP implementations. It gives enterprises a practical control layer for the point where agent reasoning becomes operational change.

    AI agents will keep gaining access to real systems. The security model has to treat every proposed action as something that can be authorized, denied, inspected, and logged before it happens.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

  • NETIZEN JOINT VENTURE WINS SPOT ON $60B NASA SOLUTIONS FOR ENTERPRISE-WIDE PROCUREMENT (SEWP) VI CONTRACT

    NETIZEN JOINT VENTURE WINS SPOT ON $60B NASA SOLUTIONS FOR ENTERPRISE-WIDE PROCUREMENT (SEWP) VI CONTRACT

    Allentown, PA: Netizen Corporation, an ISO 27001, ISO 9001, and CMMI Level 3 certified Service Disabled Veteran-Owned provider of enterprise cybersecurity and information technology (IT) solutions for defense, government, and commercial customers worldwide, was awarded a spot on NASA’s Solutions for Enterprise-Wide Procurement VI (SEWP VI) contract vehicle through their joint venture company FourNet Solutions JV, LLC (FourNet).

    SEWP VI (pronounced “Soup Six”) is a government-wide acquisition contract (GWAC) that provides federal agencies with streamlined access to a comprehensive range of Information Technology, Communications, and Audio Visual (ITC/AV) hardware, software, and service solutions. Building on the success of previous SEWP contracts – some of the most widely used procurement vehicles for IT solutions throughout the public sector – SEWP VI is designed to further simplify the acquisition process.

    The SEWP VI contract has a five-year base period and five one-year option periods, for a total ten-year ordering period, with a maximum ceiling value of $60 billion dollars. SEWP VI is currently managed by NASA’s Goddard Space Flight Center and will be available for use by all government agencies and their approved support contractors beginning around October 2026. FourNet was awarded contracts in categories B and C.

    “This SEWP VI contract award has been nearly three years in the making and is a key part of our strategic roadmap for the continued growth of Netizen into new markets and solution areas,” said Akhil Handa, Netizen’s COO. “Through our close partnership and long-term relationship with Four Points Technology, we anticipate tremendous growth in coming years driven heavily by this contract vehicle and leveraging our joint venture.”

    FourNet, the awardee, is a U.S. Small Business Administration (SBA)-certified Service-Disabled Veteran-Owned Small Business (SDVOSB) joint venture between Netizen Corporation and Four Points Technology, LLC (Four Points). Four Points, founded in 2002 and based in Herndon, Virginia, is one of the largest and most successful providers of information technology hardware, software, and services for agencies across federal, defense, and education spaces nationwide. Under the SBA Mentor-Protégé Program Agreement, Netizen serves as the Protégé and managing venturer, while Four Points serves as the Mentor aiding Netizen’s continued growth and maturity.

    About Netizen Corporation:

    Founded in 2013, Netizen is a highly specialized provider of enterprise cybersecurity and related information technology (IT) solutions. The company, a Small Business Administration (SBA) certified Service-Disabled Veteran Owned Business (SDVOSB), is headquartered in Allentown, PA with additional locations in Virginia (DC Metro) and South Carolina (Charleston). Netizen maintains ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations that demonstrate their operational maturity.

    In addition to recognition as one of the most successful businesses in the U.S. three times by Inc. Magazine in their annual “Inc. 5000” list of the nation’s fastest growing companies, Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for Veteran hiring and training, a Greater Lehigh Valley Chamber of Commerce Business of the Year and Veteran-Owned Business of the Year, and a recipient of dozens of other awards for innovation, community involvement, and growth.

    Netizen operates a state-of-the-art 24x7x365 Network Security Operations Center (NSOC) in Allentown, PA that delivers comprehensive solutions for both government and commercial clients. Their service portfolio includes network and security monitoring, cybersecurity assessments and advisory, software assurance, penetration testing, IT systems engineering, and compliance support for government and commercial markets.

    Netizen specializes in serving organizations that operate within some of the world’s most sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable. Their proven track record in these domains positions them as the premier trusted partner for organizations where technology reliability and security simply cannot be compromised.

    Learn more at https://www.Netizen.net.  

    —

    References:

    1. NASA SEWP VI Home Page (https://www.sewp.nasa.gov/sewpvi/)
    2. Welcome to FourNet Solutions (https://www.fournetsolutions.com/)
    3. Four Points Technology (https://www.4points.com/)
  • Netizen: Monday Security Brief (7/6/2026)

    Netizen: Monday Security Brief (7/6/2026)

    Today’s Topics:

    • BioShocking Shows Why AI Browsers Turn Prompt Injection Into Account Access
    • FBI Seizure of NetNut Shows How Residential Proxies Turn Home Devices Into Cybercrime Infrastructure
    • How can Netizen help?

    BioShocking Shows Why AI Browsers Turn Prompt Injection Into Account Access

    AI browsers change the risk model for web security. A normal browser displays pages, runs site code inside web security boundaries, and leaves most decisions to the user. An AI browser in agent mode can read, click, type, summarize, follow links, interact with signed-in services, and make task-level decisions inside the user’s active session. That means prompt injection is no longer just a model-behavior issue. It becomes an identity and access issue.

    LayerX’s BioShocking research, published on June 29, 2026, demonstrates that problem through a proof-of-concept attack against six agentic browsers and assistants: ChatGPT Atlas, Perplexity Comet, Fellou, Genspark Browser, Sigma Browser, and Anthropic’s Claude Chrome plugin. The attack does not rely on a memory corruption bug, stolen cookies, or malware. It relies on the agent accepting a manipulated operating context and then treating dangerous instructions as part of a task it is supposed to complete.

    The proof of concept was built as a BioShock-themed puzzle page. The agent is pushed into a false set of rules where incorrect answers are rewarded, such as accepting that 2 + 2 = 5. Once the agent adapts to that logic, the page asks it to continue the “game” by visiting a path that redirects to the victim’s work GitHub repository and copying sensitive SSH login credentials. LayerX says all six tested agents failed to identify the final step as a guardrail violation.

    The important detail is not the game theme. The important detail is that the malicious page and the user’s task arrive to the model as context the agent must interpret. That is the core failure behind indirect prompt injection: untrusted page content becomes operational instruction. OWASP’s 2025 LLM guidance lists prompt injection as LLM01 and describes it as manipulation of model behavior through crafted inputs that can cause unauthorized access, data exposure, and unsafe decisions.

    BioShocking is part of a broader pattern in agentic browser research. Brave disclosed an earlier indirect prompt injection issue in Perplexity Comet where malicious content in a web page could be processed by the assistant as instruction. In Brave’s demonstration, the assistant could move across authenticated sessions and retrieve information from services such as Gmail, exposing the limits of traditional browser security assumptions when an AI agent acts with user-level reach across sites.

    Guardio’s “Scamlexity” testing reached a similar conclusion from a scam and phishing angle. In its tests, agentic browsers interacted with fake shops, phishing pages, and hidden prompt-injection content in ways that removed the user from key decision points. The user might never inspect the sender, domain, checkout flow, or warning signs. The agent becomes the decision-maker, and attackers shift from deceiving the human to deceiving the browser assistant.

    That shift matters for enterprise security. A compromised AI browser does not need to break into GitHub, Gmail, Google Drive, a ticketing system, or an internal portal if the user is already signed in and the agent is allowed to operate inside that session. The agent becomes a delegated actor with access inherited from the user. From a defender’s view, that looks less like classic credential theft and more like misuse of a trusted identity.

    LayerX’s controlled test used a harmless plaintext file, but the attack path shows how the same technique could reach authenticated repositories, open tabs, internal tools, connected SaaS platforms, or other data sources visible to the browser session. BleepingComputer’s coverage of the research notes that LayerX’s proof of concept was tested across six mainstream agentic products, with OpenAI named as the only vendor LayerX says had a working fix at the time of publication.

    The vendor response also shows how immature this control space still is. LayerX says it submitted reports between October 2025 and January 2026. Its disclosure table states that OpenAI fixed the issue in ChatGPT Atlas, Perplexity closed or ignored the Comet report, Fellou, Genspark, and Sigma did not respond, and Anthropic attempted a patch for the Claude Chrome plugin that LayerX says did not hold. Those statuses should be treated as LayerX’s reported disclosure record, not as an independently verified statement from each vendor.

    Academic work on agentic prompt injection supports the same concern. A 2025 paper on prompt injection and data leakage in LLM agents found that tool-using agents can leak personal data observed during task execution, with attack success shaped by the task type, the data requested, and the agent’s role in extraction or authorization workflows. The authors also note that LLMs lack a clean mechanism for separating instructions from data, which is exactly the weakness BioShocking exploits in the browser.

    The defensive answer cannot be a single prompt telling the model to be careful. BioShocking shows that the model’s interpretation layer can be manipulated before the sensitive action happens. Effective controls need to sit around the agent, the browser, and the identity plane. Sensitive reads from authenticated systems should require explicit user confirmation. Agents should treat page content, comments, hidden text, URLs, documents, and third-party data as untrusted input. High-impact actions such as reading private repositories, copying credentials, sending messages, changing settings, or posting data externally should be gated by separate policy checks rather than the model’s own judgment.

    Scope control is just as important. An AI browser used to summarize a public article should not inherit access to corporate email, repositories, customer portals, admin consoles, or password managers. Agent sessions should be constrained by task, site, identity, and data class. If the user asked for help reading a page, the agent should not be able to search private GitHub repositories. If the user asked for a calendar summary, the agent should not be able to post data to an external endpoint. Least privilege has to apply to AI agents the same way it applies to service accounts.

    Security teams also need visibility. Browser agents should be logged as distinct actors, not buried inside generic user activity. Defenders need to know when an agent accessed a repository, copied a secret-like string, visited an internal tool, submitted a form, read a message, or transferred content across trust boundaries. DLP, CASB, browser security, identity governance, and endpoint telemetry all become more valuable when they can distinguish normal human browsing from agent-driven action.

    BioShocking is not just a clever jailbreak. It is a warning about what happens when agentic automation is placed directly on top of authenticated user sessions. The browser has become a control surface for AI, identity, SaaS access, and data movement at the same time. If attackers can influence the agent’s context, they may be able to influence what the user’s account does next.

    The lesson is direct: AI browsers should not be treated as safer browsers with better assistants. They should be treated as delegated identities with browser access, SaaS reach, and automation rights. Until agentic browsing has enforceable permissions, sensitive-action confirmation, untrusted-content isolation, and full auditability, every signed-in tab becomes part of the attack surface.

    FBI Seizure of NetNut Shows How Residential Proxies Turn Home Devices Into Cybercrime Infrastructure

    The FBI’s seizure of domains tied to NetNut and the Popa botnet is a clear signal that residential proxy networks have moved from a gray-market privacy problem into core cybercrime infrastructure. On July 2, 2026, NetNut’s homepage was replaced with a federal seizure notice after the FBI, IRS Criminal Investigation, Google, Lumen, Shadowserver, and other partners acted against hundreds of domains associated with the service. KrebsOnSecurity reported that NetNut is operated by Alarum Technologies, a publicly traded Israeli company, and that the seizure followed research linking NetNut to Popa, a botnet estimated at no fewer than two million compromised consumer devices.

    Residential proxy services sell access to real consumer IP addresses. To a target website, login portal, ad exchange, or fraud detection engine, traffic routed through one of these nodes can look like it is coming from a normal household internet connection instead of an obvious cloud server, VPN endpoint, or known criminal host. That makes residential proxies useful for legitimate testing and localization, but also valuable for credential stuffing, account takeover, scraping, ad fraud, spam, password spraying, and intrusion activity that needs to blend into normal user traffic. Google’s Threat Intelligence Group said suspected NetNut exit nodes were used by 316 distinct threat clusters in a single week during June 2026, including cybercriminal and espionage groups.

    The central allegation is that NetNut’s residential pool was tied to Popa, an Android proxyware ecosystem that enrolled consumer devices into a commercial proxy network. Synthient’s research describes Popa as an Android SDK that can turn phones, tablets, and streaming boxes into residential proxy nodes. Its analysis found Popa-family samples communicating with NetNut SDK endpoints, shared infrastructure at the SDK-distribution layer, and controlled-test telemetry from June 17, 2026 showing traffic from a Popa host egressing through NetNut’s commercial gateway. Synthient also states that NetNut disputes the conclusion and says it operates a lawful proxy network with customer due diligence and abuse monitoring.

    That distinction matters. A residential proxy company can claim to sell routing capacity, but the security question is how that capacity is sourced, whether device owners gave meaningful consent, and what happens once unknown third-party traffic enters a home network. Google says home devices can become exit nodes through malware preinstalled before purchase or through apps that secretly contain proxy code. Once that happens, the device owner’s IP address can be used as a launchpad for attacks, and other devices on the same local network may be exposed to internet-originated traffic routed through the compromised node.

    The consumer device angle is what makes Popa so damaging. A no-name Android TV box or free streaming app is usually treated like low-risk entertainment hardware, not like a remotely controlled network relay. Yet these devices often run outdated Android builds, ship outside trusted update channels, lack transparent software provenance, and sit on the same home network as phones, laptops, routers, work devices, and smart home systems. Once proxy code is installed, the device can run constantly, relay outside traffic, and make the homeowner’s IP address part of someone else’s operation.

    Google says it disabled Google accounts and services used by NetNut for malware command-and-control, shared technical intelligence on NetNut SDKs and backend infrastructure, and used Google Play Protect to warn users and disable apps known to include NetNut SDKs. Google also said the disruption reduced the pool of devices available to the proxy operator by millions. Reuters reported that Alarum confirmed it had been informed of the FBI seizure of certain domains and said it would cooperate with law enforcement.
    The case also points to a much larger ecosystem. Google says NetNut was widely resold and white-labeled by third-party proxy providers, meaning customers may have been buying NetNut capacity through other brands without seeing the true upstream source. This is one reason takedowns of individual providers may produce only temporary disruption. After a network loses its own botnet capacity, it can purchase capacity from competitors and reappear as a reseller. Google linked this pattern to earlier disruption work against IPIDEA and said long-term impact requires action against several interconnected providers, not one platform at a time.

    The smart TV and app ecosystem makes the problem harder to contain. Spur Intelligence scanned 6,038 LG webOS and Samsung Tizen apps and found 2,058 containing residential proxy SDKs, equal to 34.1 percent across the dataset. The reported rate was 42.5 percent for LG webOS apps and 26.9 percent for Samsung Tizen apps. That does not mean every app was tied to NetNut or Popa, but it shows that proxy SDKs are no longer limited to shady desktop utilities or mobile apps. They are being embedded into living-room software at scale.

    For defenders, the main lesson is that residential IP traffic should not be trusted just due to its source category. A login attempt from a consumer ISP address can still originate from malware, proxyware, or an attacker buying access to a hijacked device. Security controls that treat residential IPs as low risk can be exploited by operators who use proxy networks to avoid datacenter blocklists, throttle limits, geography checks, and reputation scoring. Detection logic needs to account for behavioral signals, impossible travel, session anomalies, authentication velocity, ASN drift, device fingerprint changes, and repeated failed logins spread across many residential addresses.

    Network teams should also look inward. Smart TVs, streaming boxes, and unmanaged Android devices should not share flat access with corporate systems, workstations, NAS devices, printers, or sensitive home-office equipment. At home, these devices belong on a guest or IoT network with client isolation where practical. In business environments, unmanaged media devices should be blocked or segmented. DNS logs, egress telemetry, and firewall records can help identify unexpected proxy protocols, persistent outbound connections, unknown relay infrastructure, SOCKS traffic, and beaconing to suspicious domains.

    Consumers have fewer controls, but they are not powerless. Google recommends buying connected devices from reputable manufacturers, using official app stores, checking permissions for third-party VPN and proxy apps, and keeping Play Protect active. Google’s Android certification guidance says Play Protect certified devices must pass security and compatibility testing, ship without preinstalled malware, and include Google Play Protect protections such as app scanning.
    The NetNut seizure is not just a botnet takedown. It is a reminder that the boundary between consumer electronics and attack infrastructure has eroded. A cheap streaming box, free TV app, or proxy SDK can quietly convert a household connection into a rented exit node for fraud crews, scrapers, password-spraying operators, and espionage activity. The device owner may see only a normal entertainment app. The attacker sees clean residential reach.

    That is what makes residential proxy abuse so difficult to fight. It hides inside ordinary devices, ordinary networks, and ordinary IP space. The FBI and Google action against NetNut may degrade one of the largest known networks in that ecosystem, but the broader market is adaptive, reseller-heavy, and difficult to dismantle permanently. For security teams, the right response is to treat residential proxy traffic as a serious abuse vector, treat unmanaged consumer devices as potential network relays, and stop assuming that an IP address is trustworthy just because it looks like a normal home connection.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

  • AI Agent Tooling Is Turning Metadata Into an Attack Surface

    AI Agent Tooling Is Turning Metadata Into an Attack Surface

    AI agent security is beginning to move beyond the familiar problem of malicious prompts. The more serious issue is what happens after the model is connected to real systems. Once an AI assistant can reach files, APIs, databases, SaaS platforms, code repositories, ticketing queues, and internal workflows, the security boundary is no longer just the conversation. It is the entire environment the agent can act inside.

    The Model Context Protocol, or MCP, sits directly in the middle of that shift. MCP gives AI applications a standard way to connect with outside tools and data sources. A client can ask an MCP server what tools are available, what each tool does, what parameters it accepts, and how it should be used. That structure makes agent workflows easier to build and easier to reuse across different applications.

    It also creates a new trust problem. The model is not just receiving instructions from the user. It is receiving descriptions, schemas, prompts, and parameters from tool servers. In a normal application, that kind of metadata might be treated as reference material. In an AI agent workflow, it can shape the model’s next action.

    That is where MCP tool poisoning becomes dangerous. A malicious or compromised MCP server can hide instructions inside tool metadata. The user may never type anything unsafe. The model may never be directly jailbroken. The attack can begin quietly, inside the tool description that the client loads before the user even sees a tool call.

    Once that poisoned metadata enters the model’s context, it can influence how the agent reasons about the task. A tool that appears to be a calculator, file search helper, or project utility may quietly instruct the model to read sensitive files, prefer one tool over another, log future activity, generate deceptive links, or execute commands. The tool description stops being a harmless label and starts functioning as an instruction channel.

    For organizations adopting AI agents, this changes the security question. It is no longer enough to ask whether the model is safe. The more practical question is whether the agent’s tool environment can be trusted.

    The Attack Lives in the Tool Layer

    MCP tool poisoning is a form of indirect prompt injection. Instead of placing the malicious instruction in the user’s prompt, the attacker places it in content the model is expected to consume during normal operation. That content may come from a webpage, document, retrieved record, API response, or in this case, tool metadata.

    This makes the attack path easy to miss. A user may open an AI client, connect a server, and ask the agent to complete a routine task. Behind the scenes, the client has already pulled tool descriptions from the MCP server and passed them into the model. If those descriptions contain hidden instructions, the model may treat them as part of its operating context.

    The attacker benefits from the way agent systems blend natural language with execution logic. Tool descriptions are written for the model to interpret. They explain when a tool should be used, what it can access, and how the request should be formed. A poisoned description abuses that same pathway by adding instructions that serve the attacker rather than the user.

    The result is a subtle trust inversion. The user believes the agent is responding to their request. The model may be responding to the user’s request and to hidden tool guidance supplied by an untrusted server. The client becomes the gatekeeper, yet many clients still treat tool metadata as ordinary text instead of hostile input.

    MCP Makes Agents More Useful by Giving Them More Reach

    The reason MCP is attractive is also the reason it carries risk. Agents are far more useful when they can take action. A coding assistant that can inspect a repository, run tests, search documentation, and interact with a ticketing system is more valuable than a chatbot that can only generate text. A security assistant that can query logs, enrich indicators, check asset data, and draft reports can save analysts time.

    MCP helps make those connections cleaner. A server can expose a set of tools, and the client can make those tools available to the model in a consistent way. That reduces integration friction, but it also expands the agent’s action space.

    A local MCP server might expose a filesystem, terminal, browser, database, or developer environment. A remote MCP server might expose a SaaS platform, cloud API, CRM, knowledge base, or ticketing system. In either case, the agent is being handed new ways to read, write, send, query, and execute.

    That expanded reach means poisoned metadata can have real effects. A malicious instruction inside a basic chat transcript is one problem. A malicious instruction inside an agent environment with file access, network access, OAuth tokens, or shell access is a different problem altogether.

    The model does not need to break out of anything on its own. It only needs to follow a poisoned instruction through a tool path that already exists.

    File Access Turns Prompt Injection Into Data Loss

    File access is one of the most direct ways tool poisoning can become an enterprise issue. Many AI workflows ask users to grant access to local folders, project directories, configuration files, documentation, or source code. That access may feel reasonable at setup time. The agent needs context, and local files often contain the context needed to complete the task.

    The risk appears when a poisoned tool uses that access for a different purpose. A tool can describe itself as a harmless helper, then instruct the model to read files unrelated to the user’s request. In a developer environment, those files might include SSH material, environment variables, cloud profiles, API keys, MCP configuration, repository secrets, private notes, or internal documentation.

    From the user’s point of view, the approval prompt may still look routine. The interface may show a tool name and a short description, but not the full parameter payload. It may summarize the action without showing the exact file path. It may hide long values, collapse arguments, or present the request in language that sounds harmless.

    That is why user approval alone cannot carry the security burden. A user cannot evaluate a risk they cannot see. If an approval dialog hides the sensitive file path or the outbound destination, the approval is little more than a speed bump.

    The better control is to reduce what the tool can reach in the first place. A file server that only needs access to one project should not see the user’s full home directory. A documentation assistant should not be able to read SSH keys. A code helper should not receive write access or shell access by default. The agent’s permissions need to match the task, not the broadest possible workspace.

    Poisoned Tools Can Watch the Workflow

    Data theft is not the only outcome. A poisoned tool can also try to observe how the agent is used over time.

    This can happen when a tool description claims that the tool should always run first, should monitor other tool calls, or should record user activity for performance or context. If the client passes that description into the model without filtering, the model may begin calling the tool during unrelated tasks.

    That turns the tool into a quiet surveillance point inside the workflow. It may record prompts, tool names, filenames, timestamps, project references, generated outputs, or command history. That data can reveal far more than it first appears to. It can show which clients a team supports, which incidents are active, which repositories are being changed, which systems are being queried, and which internal projects are receiving attention.

    This matters in security operations, engineering, legal work, finance, healthcare, and any other environment where workflow context has value. Attackers do not always need the final document or credential. Sometimes the sequence of actions is enough to infer priorities, processes, or weak points.

    A tool should never be allowed to grant itself priority through its own description. Tool ordering and tool selection should come from trusted client policy, explicit user intent, and approved configuration. Natural-language claims from a server should not decide which tool gets to observe the rest of the session.

    Agent-Generated Phishing Blends Into Normal Work

    Tool poisoning can also affect what the agent produces for other people. If a poisoned tool can influence the model’s output, it can push the agent to generate deceptive links inside content that looks legitimate.

    This is especially risky in business workflows. An AI assistant might draft a ticket comment, create a pull request response, prepare a Slack message, write a customer update, or generate a report. A poisoned tool can instruct the model to include a link that appears to point to a trusted destination but actually routes somewhere else.

    The attack is effective since the malicious content is not arriving as a suspicious external email. It appears inside normal work product generated by a trusted assistant. A user may review the message for tone and accuracy without checking the underlying URL. A teammate may trust the link since it came through an internal workflow.

    Clients need to make link behavior visible. If the displayed text and destination differ, the user should see that clearly. If a generated link points to an external domain, uses a shortener, includes sensitive values in the URL, or routes through an unexpected redirect, the client should warn the user before the content is sent or published.

    Agent output should not be treated as trusted simply since it came from an internal assistant. It is generated content, and generated content can carry attacker-controlled instructions forward.

    Remote Execution Is the Line That Cannot Be Soft

    The most severe MCP tool poisoning scenario is command execution. If a poisoned tool can push the model to download a script, run a shell command, install a package, or modify local configuration, the risk moves from prompt injection into host compromise.

    That risk is especially high for developer-facing AI clients. These environments often have source code, SSH keys, package managers, cloud CLIs, build pipelines, internal repositories, and deployment files within reach. A tool-poisoning attack that reaches command execution may give an attacker access to the same operational environment the developer uses every day.

    This is where soft controls break down. A model may refuse a dangerous request in one context and miss it in another. A user may approve a command after seeing a vague description. A client may treat a download or execution step as part of a normal workflow.

    Execution needs hard boundaries. Shell access should be separated from ordinary tool use. Dangerous commands should require clear, detailed approval. Remote downloads should be blocked or tightly restricted. Tools should run in sandboxes with narrow filesystem and network permissions. Outbound network access should be limited to known destinations for tools that need it.

    An agent should never inherit broad local authority for convenience.

    Better MCP Security Starts at the Client

    The MCP server exposes the tools, but the client decides what reaches the model and what the user can inspect. That makes client behavior central to the defense model.

    A secure client should treat tool metadata as hostile until it is validated. Descriptions should be scanned for hidden instructions, priority manipulation, requests to ignore user intent, sensitive file references, exfiltration language, and suspicious network behavior. Tool schemas should be checked before they are passed into the model. Parameters should be visible before execution, including full file paths, domains, commands, and outbound destinations.

    The client also needs runtime policy. Reading a README is not the same as reading an SSH key. Opening an internal documentation link is not the same as sending data to an unknown domain. Generating a report is not the same as running a downloaded script. The interface should make those differences obvious, and the policy engine should block actions that fall outside approved bounds.

    Auditability is part of the same problem. Security teams need records showing which MCP servers were connected, which tools were loaded, which tool calls were made, what parameters were used, what data was accessed, what the user approved, and what the client blocked. Without that trail, a tool-poisoning incident can become difficult to reconstruct.

    MCP Servers Should Be Treated Like Third-Party Code

    Organizations should also change how they think about MCP servers. They are not simple configuration files. They are integrations with code, permissions, dependencies, network behavior, and tool metadata that can shape agent actions.

    An MCP server from a public repository should be reviewed before it is connected to sensitive systems. Its source code, dependencies, startup commands, tool descriptions, schemas, permission requests, and network destinations should all be examined. A popular repository can still contain unsafe defaults. A legitimate server can become risky after an update. A compromised dependency can alter behavior without changing the name of the tool users recognize.

    This puts MCP servers closer to browser extensions, CI/CD plugins, and third-party SaaS integrations than ordinary documentation. They deserve an approval process, ownership, version tracking, and removal procedures.

    In enterprise environments, unmanaged MCP installation should be treated as shadow IT. A single workstation running an over-permissive local server may expose credentials, code, or customer data through an agent workflow that security teams cannot see.

    Identity Controls Still Shape the Blast Radius

    Tool poisoning often begins with instructions, but the blast radius is shaped by identity and authorization. A poisoned tool can only abuse what the agent environment can access. That makes scoped identity controls a major part of the defense.

    Remote MCP servers should require authentication. Tokens should be scoped to the correct server, user, and audience. OAuth flows should use strict redirect validation, protected state values, and clear consent screens. A server should not accept tokens meant for another service, and agent actions should be traceable across the user, client, MCP server, and downstream resource.

    That traceability matters during investigations. A log entry saying that a user accessed a file may not be enough. Security teams need to know whether the user clicked it manually, whether an AI client invoked a tool, whether a remote MCP server brokered the request, and whether the action matched an approved workflow.

    As agents gain more access, delegated identity becomes part of incident response. The more systems an agent can reach, the more important it becomes to know exactly which component acted.

    What Security Teams Should Put in Place

    The first step is visibility. Organizations need to know which AI clients are in use, which support MCP, which MCP servers are connected, which users enabled them, and which systems those servers can reach. Without that inventory, policy is mostly theoretical.

    Once the inventory exists, teams can group MCP servers by risk. A read-only documentation server is very different from a server that can execute shell commands, access source code, query production data, or send content to external APIs. Higher-risk servers should require stronger review, narrower permissions, and more logging.

    Security teams should also define minimum client controls before MCP is broadly adopted. Those controls should include metadata validation, full parameter visibility, warning prompts for risky actions, sandboxed execution, scoped filesystem access, restricted network egress, authentication for remote servers, and searchable audit logs.

    Detection should cover agent behavior directly. A newly added MCP server, a tool asking for credential paths, a tool attempting to log unrelated activity, a generated link to an unknown domain, repeated blocked tool calls, or unexpected outbound traffic from an agent process should all be visible to defenders.

    The goal is not to block MCP outright. The goal is to make sure agent tooling receives the same level of scrutiny as the systems it can reach.

    The Real Risk Is Uncontrolled Agent Action

    MCP shows where AI security is heading. The prompt still matters, but the larger risk is the connection between language and action. Once a model can call tools, read files, send data, create content, and execute commands, every piece of context that influences the model becomes part of the control path.

    Tool poisoning takes advantage of that control path. It turns metadata into instruction, instruction into tool use, and tool use into data movement or execution. The attack can feel invisible since it begins in a place users rarely inspect and ends in a tool call that may look normal on the surface.

    MCP can still be used safely, but it needs guardrails that match its role. Tool metadata should be treated as untrusted. Tool permissions should be narrow. Execution should be contained. User approvals should show the real action. Agent activity should be logged in a way security teams can investigate.

    AI agents are becoming interfaces into enterprise systems. The tool layer is where those interfaces gain the ability to act. That makes MCP security less about chatbot safety and more about controlling what connected agents can actually do.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.

  • Vulnerability Management Is Outgrowing Severity Scores

    Vulnerability Management Is Outgrowing Severity Scores

    Vulnerability management has always involved a mismatch between volume and capacity. Security teams identify thousands of findings across endpoints, cloud workloads, SaaS platforms, network appliances, containers, applications, and third-party software. Remediation teams do not have unlimited time, and many systems cannot be patched without maintenance windows, regression testing, uptime planning, or business approval.

    That is why prioritization matters. The hard part is no longer finding vulnerabilities. The hard part is deciding which vulnerabilities actually deserve immediate action.

    For years, many programs leaned heavily on severity scores. A scanner finds a CVE, maps it to CVSS, assigns a severity label, and pushes the finding into a remediation queue. That workflow is simple, repeatable, and easy to explain. It is also incomplete.

    A vulnerability with a high severity score may sit behind layers of segmentation, require conditions that do not exist in the affected environment, or affect an asset with limited business value. A vulnerability with a lower score may sit on an internet-facing identity system, a VPN appliance, a domain-joined server, or a system tied to regulated data. In practice, the second vulnerability may represent the greater operational risk.

    Modern vulnerability prioritization needs more than severity. It needs exploitability, exposure, asset value, business impact, threat activity, compensating controls, remediation feasibility, and dependency mapping. Research on vulnerability prioritization increasingly separates these dimensions into impact metrics, exploitability metrics, contextual and environmental metrics, predictive metrics, and system-level aggregation methods. A 2025 survey of 82 studies organized the field using those same categories, which reflects how far prioritization has moved beyond single-score triage.

    Severity Is a Starting Point, Not a Decision

    CVSS remains one of the most widely used ways to describe vulnerability severity. It gives security teams a common language for discussing technical impact and exploit conditions. CVSS version 4.0 also supports Threat and Environmental metrics that can adjust severity using threat intelligence and deployment context, which helps move the score closer to real risk.

    The problem begins when organizations treat a base severity score as the final remediation order.

    CVSS describes characteristics of a vulnerability. It does not automatically know whether the affected asset is exposed to the internet, whether exploit code is active, whether the system stores sensitive data, whether segmentation limits reachability, whether a compensating control blocks the attack path, or whether the patch will break a production workflow.

    The vulnerability prioritization survey makes this gap clear. More than 70% of reviewed studies used CVSS as a primary prioritization metric, yet the survey also notes that CVSS base scores are static and lack deployment-specific context.

    That limitation appears in real environments every day. A severity-only queue may put a high-scoring vulnerability on an isolated test box ahead of a lower-scoring vulnerability on an exposed authentication gateway. It may overload engineering teams with findings that satisfy scanner logic but do not map cleanly to exploitability or business risk.

    Severity should open the conversation. It should not end it.

    Exploitability Changes the Order of Operations

    Attackers do not exploit vulnerabilities in descending CVSS order. They exploit what is reachable, reliable, useful, and profitable.

    Exploitability metrics try to account for that difference. They consider whether exploitation is technically feasible, whether public exploit code exists, whether the attack requires authentication, whether user interaction is needed, whether exploitation has been observed in the wild, and whether the vulnerability is being discussed or operationalized by threat actors.

    EPSS is one of the more useful signals in this area. FIRST describes EPSS as a data-driven machine learning model that estimates the probability that a published CVE will be exploited in the wild within the next 30 days.

    CISA’s Known Exploited Vulnerabilities catalog adds another important signal: confirmed exploitation. CISA says organizations should use the KEV catalog as an input to vulnerability management prioritization, and NVD notes that federal civilian agencies must remediate KEV-listed vulnerabilities within prescribed timelines under BOD 22-01.

    These signals shift vulnerability management from theoretical severity to operational likelihood. A vulnerability that is already being exploited deserves a different response than one with a high technical score but no known exploitation, no exploit code, and limited exposure.

    The strongest prioritization programs combine severity, exploitability, and confirmed threat activity. CVSS can describe impact. EPSS can estimate near-term exploitation probability. KEV can identify vulnerabilities already used by attackers. None of these signals is perfect alone. Together, they give teams a better starting point than severity alone.

    Context Is Where Risk Becomes Real

    The same CVE can create very different risk across two organizations, or even across two assets inside the same organization.

    A vulnerability on an internal lab server may be tolerable for a short period. The same vulnerability on an externally exposed VPN appliance may demand immediate action. A flaw in a low-value kiosk system may create limited risk. The same flaw in a clinical system, payment environment, identity provider, or domain controller may carry major operational consequences.

    Contextual prioritization brings asset and environment data into the scoring process. That includes asset criticality, network exposure, business function, data sensitivity, user population, compensating controls, system dependencies, uptime requirements, and remediation difficulty.

    The vulnerability prioritization survey identifies contextual and environmental factors as a distinct metric category, including business impact, system impact, network and host exposure, and operational feasibility.

    This is where many programs struggle. Vulnerability scanners can produce findings, but scanners often lack full asset context. CMDBs may be incomplete. Cloud inventories may change constantly. Business owners may not keep asset tags current. Network exposure may shift after a firewall change, cloud deployment, or remote access update.

    Without context, prioritization becomes guesswork with scores attached.

    A mature program connects scanner output to asset inventory, identity data, network topology, EDR visibility, exposure management, ticketing history, business ownership, and service criticality. The goal is to rank vulnerabilities based on where they sit in the organization’s actual operating environment.

    Exposure Should Change Urgency

    Exposure is one of the most practical prioritization signals. A vulnerable system reachable from the public internet carries a different level of urgency than the same system reachable only from a segmented subnet. A vulnerability on an asset accessible from partner VPNs, vendor networks, guest wireless, or cloud peering links may also need faster attention than one buried deep inside a restricted environment.

    Network exposure also interacts with exploit complexity. A remotely exploitable vulnerability on an internet-facing appliance is a common path into organizations. A local privilege escalation vulnerability may matter less on a locked-down workstation, but more on a system where attackers already have a foothold or where remote access services are exposed.

    Graph-based prioritization methods help here. They model systems, dependencies, trust relationships, attack paths, and propagation routes. The survey describes graph-based methods as useful for analyzing attack paths, dependencies, and cascading effects across complex environments.

    This type of modeling matters since vulnerabilities rarely exist in isolation. An attacker may chain a perimeter flaw, weak credential control, lateral movement path, and privilege escalation bug. A single CVE may look moderate in isolation but become high risk when it sits on a path to a crown-jewel asset.

    Prioritization should ask where a vulnerability can lead, not just what the vulnerability is.

    Business Impact Belongs in the Queue

    Technical risk and business risk overlap, but they are not identical.

    A vulnerability on a billing system may affect revenue. A vulnerability on a healthcare system may affect care delivery. A vulnerability on a manufacturing system may affect safety, uptime, or production. A vulnerability on a legal document system may affect confidentiality obligations. A vulnerability on an identity platform may affect nearly every connected application.

    Business impact helps translate vulnerability management into operational decision-making. It also helps justify remediation urgency to teams outside security.

    This is especially useful when patching carries risk. Some assets cannot be patched immediately without downtime, vendor coordination, testing, or replacement planning. In these cases, prioritization must account for operational feasibility. The right decision may be patching, virtual patching, segmentation, compensating control deployment, service isolation, or scheduled remediation tied to a maintenance window.

    The survey’s discussion of industrial trends points to growing use of context-aware and multi-domain metrics that incorporate asset criticality, operational impact, network topology, device characteristics, compensating controls, and position inside industrial networks.

    That direction matches what many organizations already need. Patching everything immediately is not realistic. Patching based only on scanner severity is inefficient. Ranking based on technical risk and business consequence produces a queue that operational teams can actually defend.

    Predictive Scoring Can Help, but It Must Be Explainable

    Machine learning can improve vulnerability prioritization by analyzing historical exploitation, exploit code availability, vulnerability text, software vendor patterns, references, social signals, and other indicators that may predict future exploitation. The survey describes predictive metrics as forward-looking signals that use statistical and machine learning models to anticipate exploitation or changing impact.

    That is useful at scale. Large environments can generate too many findings for manual analysis. Predictive scoring can surface vulnerabilities likely to become weaponized before they appear in active exploitation catalogs.

    The limitation is trust. If a model ranks a vulnerability as urgent, analysts and remediation owners need to know why. A black-box score with no explanation may be ignored, challenged, or applied inconsistently. The survey identifies explainability as a major issue for advanced prioritization methods, noting that some ML-based models perform well but lack interpretability for practitioners who need clear justifications.

    Explainability should be built into the workflow. A prioritization engine should show which factors drove the ranking: active exploitation, exploit code, internet exposure, asset criticality, sensitive data, lateral movement potential, business function, control gaps, or remediation deadline.

    Security teams need rankings they can defend in change boards, engineering meetings, audits, and incident reviews.

    Compliance Deadlines Can Conflict With Risk-Based Triage

    Vulnerability management is also shaped by compliance requirements. PCI DSS, HIPAA-related security expectations, NERC CIP, FedRAMP, customer contracts, cyber insurance requirements, and internal policies may impose remediation timelines based on severity labels or asset classes.

    That can create friction. A compliance-driven deadline may require a medium-risk vulnerability to be patched within a set time window, even when threat activity points to a different vulnerability as the larger immediate risk. A purely risk-driven queue may conflict with audit requirements if it does not track policy timelines.

    The survey notes that compliance remediation timelines can conflict with risk-based approaches and calls for prioritization methods that integrate standards such as CVSS, CPE, and SCAP with compliance-driven metrics such as SLA deadlines.

    Security teams should not treat this as an either-or problem. The remediation queue needs both risk urgency and compliance accountability. A finding can be low exploitation risk and still require closure for audit. A finding can sit outside a strict compliance clock and still require emergency response due to active exploitation.

    The ticketing workflow should make both visible.

    Data Quality Can Make or Break Prioritization

    A prioritization model is only as good as the data behind it.

    Scanner data can be noisy. Asset inventories can be stale. Software detection can be wrong. Internet exposure data can lag behind infrastructure changes. Threat intelligence can be incomplete. Vulnerability records can lack detail. Exploit availability can change quickly. Business ownership data can be outdated.

    The survey found that most reviewed studies relied on standard vulnerability databases such as CVE and NVD, with 70 of 82 using those sources. It also identifies data quality issues, including inconsistent vulnerability feeds, bias, and gaps that can skew prioritization.

    This matters in production security programs. A high-risk vulnerability may be missed if the affected software is not detected. A vulnerability may be over-prioritized if a scanner flags a package that is present but not reachable or loaded. A ticket may sit untouched if ownership data points to the wrong team.

    Improving prioritization requires improving the underlying data pipeline. Asset management, vulnerability scanning, SBOM data, EDR telemetry, cloud inventory, external attack surface management, threat intelligence, and ticketing systems all need to feed each other.

    The scoring model cannot fix missing context that was never collected.

    A Practical Prioritization Model

    A practical vulnerability prioritization model should begin with severity, then enrich it.

    The first layer is technical severity. CVSS still has value as a common baseline for impact and exploit characteristics. The second layer is exploitation likelihood, using signals such as EPSS, exploit code availability, active scanning, malware integration, and KEV status. The third layer is exposure, including internet reachability, network segment, authentication boundary, and attack path position.

    The fourth layer is asset context. This includes asset criticality, data sensitivity, business owner, regulatory scope, identity role, and dependency on other systems. The fifth layer is operational feasibility, including patch availability, downtime risk, compensating controls, maintenance windows, vendor constraints, and rollback options.

    The final output should not just be a score. It should be a decision record. It should explain why the vulnerability is ranked where it is, what action is recommended, which team owns it, what deadline applies, and what compensating controls are acceptable if patching cannot happen immediately.

    This turns vulnerability management from scanner output into risk operations.

    What Security Teams Should Change

    Organizations that still prioritize mainly by CVSS should start by adding exploitability and exposure data. KEV-listed vulnerabilities, high-EPSS vulnerabilities, externally exposed assets, and identity-facing systems should receive special attention.

    Security teams should connect vulnerability data to asset inventory and business ownership. A finding without an owner is a delayed remediation. A finding without asset context is an incomplete risk decision.

    Programs should also define exception paths. Some vulnerabilities cannot be patched immediately. The process should require documented compensating controls, business acceptance, expiration dates, and review checkpoints rather than letting exceptions become permanent.

    Metrics should shift from raw vulnerability counts to risk reduction. Total findings matter less than exploitable findings on critical assets, internet-exposed vulnerabilities, KEV remediation performance, SLA compliance, exposure reduction, and time to remediate vulnerabilities with active exploitation.

    The larger goal is to make remediation effort match attacker opportunity and business impact.

    The Future of Vulnerability Management Is Context-Aware

    Vulnerability management is becoming less about counting flaws and more about ranking risk under operational constraints. Severity scores still matter, but they are no longer enough for environments where attackers move fast, infrastructure changes constantly, and remediation capacity is limited.

    The next stage is context-aware prioritization. That means scoring vulnerabilities based on technical impact, exploitation likelihood, asset criticality, exposure, business function, system dependencies, compliance deadlines, and operational feasibility.

    It also means being honest about tradeoffs. Some vulnerabilities need emergency patching. Some need mitigation until a maintenance window. Some need segmentation more than a patch. Some need ownership cleanup before remediation can even begin.

    Security teams that mature past severity-only triage will make better use of limited remediation capacity. They will reduce the risk that matters most, create clearer justification for patching decisions, and build vulnerability programs that map more closely to the way attacks actually unfold.

    How Can Netizen Help?

    Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally. 

    Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.

    Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.

    Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.