Netizen Blog and News

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

recent posts

about

  • When Metadata Becomes an Attack Path

    When Metadata Becomes an Attack Path

    Metadata is easy to dismiss as background information. A document has an author, creation date, file path, revision history, and perhaps a few tags. A photograph may contain location data and device information. A cloud instance has an identifier, region, role, and networking details. A Kubernetes object carries labels and annotations that help administrators organize and control resources. None of these fields immediately look like an attack surface, yet many modern systems rely on metadata for far more than description.

    The security issue begins when metadata starts carrying information about identity, trust, authorization, location, provenance, or system state. At that point, it can become useful to an attacker in several ways. Metadata can expose internal information during reconnaissance, reveal credentials through cloud services, influence security controls, provide attackers with opportunities to hide activity, or affect how infrastructure behaves. In some environments, changing a small piece of metadata can alter the way a security product, operating system, or orchestration platform treats an object.

    Metadata Can Reveal More Than the File Itself

    One of the oldest metadata risks comes from ordinary business documents. Microsoft Office files can contain author information, usernames, creation and modification dates, comments, tracked revisions, hidden text, external links, template names, document-server properties, and other details that are not always obvious to someone reading the finished document. Microsoft includes Document Inspector in Office largely to identify and remove this information before files are shared outside an organization.

    This kind of information can be useful during reconnaissance. A public proposal might expose internal usernames or departmental naming conventions. A spreadsheet could contain references to network paths or internal resources. A document’s revision history could identify employees involved in a particular project, and a template name could reveal how an organization structures its internal documentation. None of this requires exploiting a vulnerability in Word or Excel. The attacker simply needs access to a file that the organization intended to publish.

    Image metadata can create similar problems. Photographs may contain EXIF information describing the camera or phone used, the time the image was taken, and, in some cases, geographic coordinates. A photograph uploaded from an office, production facility, government site, or employee’s home can unintentionally reveal far more than the visible image. A single photograph may not expose much on its own, but multiple images taken over time can help establish locations, schedules, travel patterns, device types, and other operational details.

    This is where metadata becomes particularly useful for attackers. Individual data points often appear harmless in isolation. A username, timestamp, filename, geographic coordinate, software version, or project name may seem insignificant. Combined with information collected from social media, public documents, job postings, exposed infrastructure, and breach data, those details can help an attacker build a much clearer picture of an organization before direct access is ever attempted.

    Cloud Metadata Can Carry Credentials

    Cloud infrastructure made metadata significantly more security-sensitive. Amazon EC2 instances can communicate with the Instance Metadata Service, commonly called IMDS, through a local address that is accessible from the instance itself. The service provides information about the instance and its environment, including networking details, instance identifiers, IAM role information, and temporary credentials associated with an attached role.

    Those credentials make the metadata service part of the cloud identity system rather than a simple inventory service. An application running on an EC2 instance may legitimately need access to the metadata endpoint, but that same access can become dangerous if the application contains a server-side request forgery vulnerability. SSRF can allow an attacker to make the vulnerable application send requests to internal resources that the attacker cannot reach directly. In a cloud environment, the metadata endpoint can become one of the most valuable targets available from inside the host.

    The 2019 Capital One breach remains a widely cited example of this type of attack chain. According to the U.S. Department of Justice and public analysis of the incident, a misconfigured web application firewall was abused through SSRF to obtain credentials associated with an AWS IAM role. Those credentials were then used to access data stored in Amazon S3. The important security lesson was not simply that SSRF existed. The attacker was able to use the server’s own trusted position inside the cloud environment to reach a service that provided identity credentials.

    AWS later placed greater focus on IMDSv2, which requires a session token before metadata can be retrieved. IMDSv2 adds several controls intended to make common SSRF techniques harder to use against the metadata service. AWS also recommends disabling the older IMDSv1 where workloads support the newer version. These protections reduce exposure, but IAM permissions remain just as significant. If a workload’s role has excessive access, stolen temporary credentials can still give an attacker far more reach than the compromised application itself requires.

    Metadata Can Determine Whether a File Is Trusted

    Windows provides another example of metadata moving directly into a security decision. Files downloaded from the internet can receive Mark-of-the-Web information through the Zone.Identifier alternate data stream on NTFS. Windows, Microsoft Office, Microsoft Defender SmartScreen, and other security controls can use this origin information to treat an internet-downloaded file differently from one that originated locally.

    Microsoft Office, for example, can open internet-originated documents in Protected View. Microsoft also blocks many VBA macros by default when Office files are identified as having come from the internet. In these cases, metadata is no longer just describing where a file came from. It helps determine how much trust the operating system or application grants to that file.

    Attackers have repeatedly looked for ways to remove or bypass this information. MITRE ATT&CK tracks Mark-of-the-Web bypass techniques under T1553.005. One historical approach involved delivering malicious files inside container formats such as ISO or virtual disk images, where extracted or mounted content did not always retain the same internet-origin metadata as the original downloaded container. Microsoft has changed portions of this behavior over time, but the broader technique demonstrates why provenance metadata has become valuable to both attackers and defenders.

    The defensive implication is that provenance should be monitored across a file’s entire lifecycle. Security products may correctly identify that a downloaded archive came from the internet, yet a file extracted from that archive could lose the metadata that caused stricter protections to apply. Detection logic can account for this by correlating an internet-originated parent file with child files that unexpectedly lack equivalent origin information before execution.

    File Metadata Can Be Used to Rewrite an Incident Timeline

    Attackers can also manipulate metadata after gaining access to a system. File timestamps are among the most common examples. MITRE ATT&CK documents timestamp modification under the Timestomp technique, T1070.006. Malware and intrusion tools can alter creation, modification, access, and change times so that malicious files appear older than they really are or resemble nearby legitimate files.

    Timestamp manipulation matters because incident responders rely heavily on chronology. Analysts often use file creation and modification times to determine when malware appeared, whether multiple artifacts were introduced together, or which changes occurred during the suspected intrusion window. If those timestamps have been altered, the resulting timeline may point investigators in the wrong direction or make a malicious file appear to predate the compromise.

    NTFS can store timestamp information in multiple structures, which sometimes gives forensic analysts a way to identify inconsistencies between different copies of the same timestamp. More capable tools can modify several of these records, making detection harder. Threat actors documented by MITRE have used timestamp manipulation for years, including groups such as APT28, APT29, and Lazarus Group, along with numerous malware families and post-exploitation frameworks.

    This means file metadata cannot always be treated as authoritative forensic evidence. Timestamps are far more useful when compared against other telemetry such as process creation logs, EDR events, filesystem journal records, authentication logs, and network activity. An attacker may be able to modify metadata stored on a filesystem, but changing every independent record describing the same activity is significantly harder.

    Cloud-Native Infrastructure Depends Heavily on Metadata

    Kubernetes illustrates how metadata can influence the operation of an entire platform. Kubernetes objects commonly use labels and annotations to describe workloads, organize resources, connect components, store deployment information, and communicate instructions to supporting systems. Labels can be used by selectors to determine which pods belong to a service or deployment, and annotations can store information used by ingress controllers, monitoring systems, service meshes, automation tools, and other components.

    Some of this metadata also affects security policy. Kubernetes Pod Security Admission can use namespace labels to determine which Pod Security Standard applies to workloads. A namespace can be labeled so that pods are evaluated against baseline or restricted policy levels. Once metadata starts deciding which security policy applies to a workload, control over that metadata becomes part of the policy itself.

    OWASP has identified metadata trust abuse as a concern in Kubernetes environments for this reason. Third-party controllers and platform components often make decisions based on labels or annotations, and administrators may not always treat write access to those fields with the same seriousness as direct access to the underlying security configuration. If an attacker can alter metadata that a controller trusts, the attacker may be able to influence routing, policy enforcement, deployment behavior, or monitoring without directly modifying the component that performs the action.

    This creates a broader cloud-native security principle. Metadata should be protected according to the decisions that depend on it. A label used solely for inventory may have little security impact. A label used to determine policy scope or network behavior deserves stronger access controls, auditing, and change monitoring.

    Detection Systems Also Trust Metadata

    Security tools themselves rely extensively on contextual information. SIEM platforms, EDR products, cloud security tools, and threat intelligence systems use metadata to correlate events and decide which activity deserves attention. Hostnames, account identities, file paths, timestamps, process relationships, geolocation, asset classifications, labels, severity values, and resource tags can all affect how an alert is interpreted.

    This creates another opportunity for abuse. If an attacker can manipulate the contextual data that defenders use, they may be able to change how an event appears without changing the event itself. Timestomping can make a malicious file appear old. Renaming tools can make them resemble legitimate software. Altering resource labels can affect how cloud or orchestration policies apply. Manipulating file locations or ownership information can make malicious artifacts appear consistent with normal system activity.

    MITRE tracks several of these behaviors under techniques such as Masquerading and Indicator Removal. The shared theme is that attackers attempt to interfere with the contextual information defenders depend on to reconstruct activity. This is particularly significant for automated detection pipelines, where metadata may be used to make decisions at machine speed without a human analyst reviewing every assumption behind the alert.

    Detection engineering should account for this by distinguishing between metadata that is independently generated and metadata that can be controlled by the system or user being monitored. A hostname reported by a centrally managed inventory service carries a different level of confidence from a filename chosen by an attacker. A cloud identity recorded by the provider may be more trustworthy than an application-supplied field. Understanding who can modify each piece of contextual information helps determine how much weight it should receive during detection and investigation.

    Metadata Needs Its Own Security Classification

    The answer is not to strip every piece of metadata from every system. Metadata is fundamental to modern infrastructure, collaboration, forensics, automation, and security monitoring. Removing it indiscriminately would eliminate information that defenders and administrators rely on every day. The more useful approach is to classify metadata according to what exposure or modification would allow an attacker to accomplish.

    Document and media publication workflows can include metadata inspection before external release. Cloud environments can restrict access to instance metadata services, enforce modern metadata protocols, and keep workload IAM permissions narrow. Windows defenders can monitor whether file-origin metadata disappears unexpectedly during extraction or execution. Kubernetes administrators can restrict who is allowed to modify labels and annotations that influence policy or infrastructure behavior. Incident responders can corroborate filesystem timestamps with independent telemetry rather than assuming that local metadata reflects an accurate history.

    The security significance of metadata depends less on what the field is called and more on what the surrounding system does with it. A location field can expose a sensitive facility. A cloud metadata endpoint can expose temporary credentials. A small NTFS data stream can determine whether Office macros execute normally. A Kubernetes label can influence the policy applied to a workload. A timestamp can reshape an incident timeline.

    Metadata is often treated as secondary information surrounding the thing defenders actually care about. Modern infrastructure increasingly proves that distinction false. Once systems use metadata to establish trust, identity, provenance, routing, or policy, it becomes part of the attack surface and needs to be protected accordingly.

    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 (9/28/2026)

    Netizen: Monday Security Brief (9/28/2026)

    Today’s Topics:

    • Google’s €403 Million Fine Shows the Cost of Losing Control of Location Data
    • CMMC Phase II Is Paused, but Defense Contractors Still Have Work to Do
    • How can Netizen help?

    Google’s €403 Million Fine Shows the Cost of Losing Control of Location Data

    Sankt-Petersburg, Russia, November 8, 2017: A woman’s hand is touching screen on tablet computer iPad Pro at night for searching on Google search engine. Google is the most popular Internet search engine in the world. Photo taken at company office.

    On September 21, Ireland’s Data Protection Commission fined Google €403 million over its handling of location data, closing an inquiry that examined several of the company’s most familiar location-related features. The regulator found violations of the European Union’s General Data Protection Regulation connected to Web & App Activity, Location History, and Location Accuracy, covering data processing between May 25, 2018, when the GDPR became applicable, and February 4, 2020. Google must bring the affected processing into compliance within six months.

    The size of the penalty draws attention, but the findings behind it are more relevant for organizations collecting sensitive telemetry. The DPC did not identify a single isolated privacy failure. It found issues involving lawfulness and fairness in Web & App Activity and Location History, failures to demonstrate compliance for Location Accuracy, transparency problems affecting all three features, and excessive retention involving Web & App Activity and Location History. Those findings reach several separate parts of the GDPR rather than treating location tracking as one narrowly defined consent problem.

    Location information carries particular risk since individual data points can become much more revealing once they are combined over time. A location service can identify places a user visits, routes traveled, daily habits, and recurring patterns. In its decision announcement, the DPC said location data can reveal information that is inherently private and warned that users could have been unaware their location information was being used to influence advertising or infer interests. The regulator also found that retaining location information longer than necessary increased the loss of control experienced by users.

    The three services examined by regulators also operated differently. Web & App Activity can store activity from Google services, including searches, browsing activity, and location-related information. Location History, which users opt into, has been used to build a private Timeline showing places visited and paths traveled. Location Accuracy is an Android feature used to improve device positioning beyond GPS alone and can operate for Android users regardless of whether they hold a Google Account. The DPC’s findings show why privacy reviews cannot stop at the most visible location setting in a product. Location information can be generated, retained, or inferred through several connected features.

    Google disputes the relevance of the practices examined to its current products. The company told Reuters that the case concerns older policies and said it has made major changes since the period covered by the investigation. Google pointed to stronger location controls, automatic deletion features, and changes intended to store less precise location information. Those changes do not erase the regulator’s findings for the 2018-to-2020 period, but they matter when assessing how closely the enforcement action reflects Google’s current systems.

    For other companies, the case shows that giving users a setting or toggle does not settle the compliance question. Regulators can examine what information a feature collects, the legal basis for processing it, what users were told, how long the information remained available, and whether the organization can demonstrate that its practices complied with the law. Accountability matters alongside technical controls. An organization may need evidence explaining why information was collected, how its processing was justified, how users were informed, and when the information was deleted.

    Retention deserves particular attention. Organizations often focus privacy programs on collection and consent, then leave historical data in storage long after its immediate operational purpose has passed. Location records make that approach especially risky. A single coordinate may reveal little. Months or years of coordinates can describe patterns that were never explicitly provided by the person whose device generated them.

    The decision also illustrates how old data practices can create current regulatory exposure. The DPC opened its inquiry in February 2020 after complaints from European consumer organizations, yet the final €403 million decision arrived more than six years later. Systems, interfaces, privacy controls, and internal policies can all change during an investigation, but organizations may still have to account for how personal information was handled years earlier.

    CMMC Phase II Is Paused, but Defense Contractors Still Have Work to Do

    The Department of War suspended Phase II of the Cybersecurity Maturity Model Certification program on July 13, halting a transition that had been scheduled to begin November 10, 2026. Phase II was expected to expand the use of Level 2 assessments conducted by Certified Third-Party Assessment Organizations, making independent certification a much larger part of the contracting process. The department instead opened a review of the program focused on cost, scalability, participation by smaller companies, and the burden placed on the defense industrial base.

    The suspension is easy to misread as a broader retreat from CMMC. It is not. Current DoW guidance says implementation is paused in Phase I, and Phase I self-assessment requirements remain in effect. Companies handling Federal Contract Information can still face Level 1 requirements based on the 15 safeguards in FAR 52.204-21. Contractors handling Controlled Unclassified Information can still face Level 2 self-assessment requirements tied to the 110 controls in NIST SP 800-171 Revision 2.

    For Level 1, organizations perform an annual self-assessment and submit the result to the Supplier Performance Risk System. Level 2 self-assessments remain valid for three years, paired with an annual affirmation of compliance. Limited Plans of Action and Milestones remain available for Level 2 self-assessments under the CMMC rules, with required closeout procedures. The current DoW guidance states plainly that pausing CMMC implementation in Phase I does not eliminate contractor obligations under DFARS 252.204-7012.

    That distinction matters for companies that had been preparing for a C3PAO assessment. The external certification deadline may no longer be approaching on the original November 2026 schedule, but the security controls behind the program did not disappear. Contractors that store, process, or transmit CUI still need to know where that information resides, which systems fall inside the assessment boundary, which NIST SP 800-171 controls apply, and whether their documented assessment results match their actual security posture.

    The department created a CMMC Reform Task Force as part of the suspension and announced a 60-day review of the program. The department said the review would examine ways to reduce barriers for small, medium-sized, and nontraditional defense businesses and replace unnecessary compliance burden with cybersecurity measures that can scale across the industrial base. Recent material published through the DoW CIO site indicates that officials have continued evaluating public and industry input. One recurring issue identified through listening sessions and responses has been inconsistent government designation and marking of CUI, which can make it harder for contractors to determine what information actually falls within protected environments.

    That issue cuts directly into one of CMMC’s hardest operational problems. A contractor cannot accurately scope an assessment if it cannot reliably identify the information that creates the scope in the first place. Poor CUI marking can cause companies to protect systems that may not need to be in scope, increasing cost, or exclude systems that contain information requiring protection. For smaller suppliers, either mistake can be expensive.

    The Phase II suspension also changes the immediate role of third-party certification. Phase II had been scheduled to make Level 2 certification assessments applicable to more solicitations beginning November 10. Under the current pause, DoW says the program may require only self-assessments at Levels 1 and 2 during Phase I. NIST SP 800-171 Revision 2 compliance can still be checked through contractor self-assessments and selected government-led assessments.

    Contractors also need to separate CMMC from the contractual cybersecurity clauses that preceded it. DFARS 252.204-7012 already requires applicable contractors handling covered defense information to provide adequate security and implement NIST SP 800-171 requirements. CMMC created a structured assessment and verification model around those requirements. Pausing part of that verification model does not erase the underlying contractual duty.

    The current period may give contractors more time before third-party certification becomes broadly required, but it also creates uncertainty about what the revised program will look like. The original CMMC implementation schedule called for Phase II in November 2026, Phase III in November 2027, and full implementation in November 2028. The Phase II suspension disrupted that schedule, and the department has not published a replacement Phase II date on its current CMMC pages.

    That makes the pause a poor reason to abandon work already underway. Asset inventories, CUI data-flow mapping, access controls, multifactor authentication, logging, incident-response procedures, configuration management, supplier controls, security plans, and accurate SPRS submissions retain value under the requirements that remain active. They also put contractors in a better position if independent certification returns under a revised structure.

    CMMC reform may change how compliance is verified and which organizations require third-party assessment, but the current federal position still expects defense contractors to protect CUI and document that protection. For organizations in the defense industrial base, the question has shifted from preparing for one fixed November 2026 deadline to maintaining defensible security practices during a period in which the certification model itself is being reconsidered.

    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.

  • FBIJobs Breach Raises Questions About ShinyHunters’ PeopleSoft Zero-Day

    FBIJobs Breach Raises Questions About ShinyHunters’ PeopleSoft Zero-Day

    The FBI is investigating claims that the ShinyHunters cybercrime group compromised FBIJobs.gov and obtained a large collection of personnel and applicant information, including records that appear to identify employees working in sensitive intelligence, surveillance, and counterintelligence roles. ShinyHunters says it entered through a previously unknown Oracle PeopleSoft vulnerability and ultimately stole between two and three terabytes of data, but those central claims remain unverified. The FBI’s public statement stops short of confirming either a breach of its enterprise systems or the theft of data.

    The bureau said on September 23 that it was aware of a cybercriminal group claiming a compromise of the FBIJobs.gov portal and an impact to employee personally identifiable information. Investigators have not determined whether the initial point of compromise was a third-party provider or part of the FBI’s own enterprise, according to the agency. The FBI said it is working with third parties that support FBIJobs.gov as the investigation continues.

    Evidence published outside the FBI has given the incident considerably more weight than a typical criminal leak claim. ShinyHunters provided journalists with a spreadsheet containing roughly 5,000 records it says came from the intrusion. Reuters independently verified personal details belonging to more than 22 people in that dataset by comparing the information with credit records and previous data leaks. Reuters also matched career information or job titles for eight people against court filings, news reports, public professional profiles, and social media posts. The outlet could not authenticate the spreadsheet in full or establish that all listed assignments are current.

    The records reviewed by Reuters contain names, addresses, telephone numbers, dates of birth, Social Security numbers, emergency-contact information, field-office assignments, and job information. Reuters found 14 people identified with China-related work, nine with Russia-related roles, three with Iran- or Hezbollah-focused intelligence work, 18 associated with interception, covert access, surveillance, or clandestine technical operations, and another 11 listed in human intelligence roles. Some of the unit names were sensitive or had received little previous public attention.

    404 Media separately reported that the sample included people connected to the FBI’s Remote Operations Unit, a little-publicized technical unit involved in developing or using tools that remotely access target devices. The publication had previously received a roughly 5,000-record sample containing names, addresses, telephone numbers, and information related to employees’ spouses. The presence of operational assignments alongside personal and family information is one of the clearest reasons the incident carries risks far beyond conventional identity theft.

    FBIJobs Sits Close to Sensitive Personnel Systems

    The architecture documented for FBIJobs.gov helps explain how a recruiting platform could contain or interact with data carrying much greater sensitivity than a typical careers website. A Department of Justice privacy assessment published in 2022 describes the FBI Candidate Gateway as an internet-accessible recruiting and hiring system hosted on AWS GovCloud. At that time, the system used Oracle PeopleSoft HRS 9.2, Oracle Database 19c, and Drupal, and it integrated with the FBI’s internal HR Source environment.

    The same document says HR Source resides on FBINet and that the Candidate Gateway exchanged information with it using accredited cross-domain mechanisms. Applicant profile information, completed applications, employment questionnaires, messages to FBI recruiting personnel, and offers could move from the internet-facing Candidate Gateway into HR Source. Information could also move in the other direction, including job postings, application information, questionnaires, recruiter communications, and employment offers.

    The Candidate Gateway was documented as collecting sensitive but unclassified PII including names, Social Security numbers, dates of birth, citizenship information, addresses, phone numbers, applicant information, employment records, and some health-related information. Once an application was submitted, the 2022 assessment said application PII was transferred into HR Source, with the Candidate Gateway later purging that information subject to retention requirements.

    That documentation does not establish what the FBIJobs environment looked like on September 21, 2026. Four-year-old architecture records cannot prove which software releases were still running, whether the same integrations remained in place, or which systems ShinyHunters accessed. They do establish that the recruiting environment historically had direct functional ties to internal personnel processes and that PeopleSoft and AWS GovCloud were part of the documented design.

    That distinction has become central to the incident. ShinyHunters claims it moved from the PeopleSoft environment into FBI-managed AWS GovCloud systems and accessed services associated with human resources, MedLink, and criminal justice information. BleepingComputer reported those claims but said it could not independently verify the alleged zero-day, lateral movement, or two-to-three-terabyte data haul. The FBI has made no public statement confirming access to those internal services.

    A Claimed New PeopleSoft Zero-Day

    ShinyHunters says the intrusion began Monday night after the group found another PeopleSoft zero-day and immediately used it against FBI infrastructure. The group told BleepingComputer that the vulnerability provided remote code execution and remained unpatched at the time of the attack. It also claimed that the same flaw was being used against other organizations, including Fortune 500 companies. None of those technical claims has been independently substantiated.

    As of September 24, Oracle has not published a public security alert identifying a new PeopleSoft vulnerability tied to the FBI incident. The relevant public Oracle alert remains CVE-2026-35273, disclosed June 10, which affects the Environment Management component in supported PeopleTools 8.61 and 8.62 releases. Oracle rates the flaw at CVSS 9.8 and says it can be exploited remotely without authentication to achieve remote code execution.

    That earlier flaw matters since Google Threat Intelligence Group and Mandiant already tied ShinyHunters activity to its exploitation. Google observed activity attributed to UNC6240, which it associates with ShinyHunters, between May 27 and June 9. The exploitation occurred before Oracle’s June 10 alert, meaning CVE-2026-35273 was used as a zero-day during the campaign.

    Google’s investigation documented attackers targeting exposed PSEMHUB endpoints, deploying customized MeshCentral agents, mapping internal PeopleSoft environments, executing lateral-movement scripts, staging stolen information, and connecting infrastructure back to the ShinyHunters data-leak operation. Google notified more than 100 organizations whose addresses corresponded with potentially vulnerable endpoints, with 68 percent of those organizations operating in higher education.

    There is no evidence at this point that CVE-2026-35273 was the vulnerability used against FBIJobs.gov. ShinyHunters is explicitly claiming that it found a different PeopleSoft flaw. The FBI’s 2022 documentation confirms PeopleSoft was part of the Candidate Gateway architecture, but it does not identify the PeopleTools version running during the September 2026 incident. Connecting the FBI intrusion to CVE-2026-35273 without further evidence would go beyond what is publicly established.

    The Data May Carry Counterintelligence Value

    The clearest concern in the material reviewed so far is the combination of personal identifiers and operational information. A name or telephone number alone has limited intelligence value. A record tying the same person to a specific counterintelligence target, surveillance capability, human intelligence program, or technical unit can provide an adversary with a much more useful profile.

    Reuters found personnel listed in China intelligence and technology-transfer roles, Russia operations, Iran and Hezbollah intelligence work, telecommunications interception, covert-access programs, clandestine technical operations, electronic surveillance, and human intelligence management. Reuters could not establish that each assignment remained current, but it independently corroborated career information for several people.

    Current assignments are also not the only concern. Historical records can reveal organizational structures, relationships between field offices and headquarters units, previous areas of responsibility, and personnel who have worked in sensitive programs. Combined with commercial data, social media, previous leaks, and open records, that information can support targeting far beyond the original dataset.

    Emergency contacts and spouse information add another layer of exposure. Reuters reported emergency-contact details in the spreadsheet, and 404 Media said its sample contained information about employees’ spouses. Family members can present an alternate route for social engineering, impersonation, harassment, or attempts to collect information about an employee whose own security practices are harder to defeat.

    Applicants also represent a valuable target set. FBI applicants expect communications about interviews, background checks, scheduling, medical requirements, and hiring decisions. The FBI’s privacy documentation confirms that the Candidate Gateway handled applicant contact information, questionnaires, supporting material, and communications with recruiters. Someone possessing real application information could use that context to create convincing impersonation attempts directed at people already expecting contact from the bureau.

    ShinyHunters Says the Attack Was Retaliation

    ShinyHunters says the operation was driven by a dispute with the FBI rather than a conventional ransom demand. The group objected to FBI reporting published in May describing ShinyHunters as a cybercriminal organization involved in large-scale data theft and extortion and warning that actors using the name can make real or exaggerated claims of access, harass victims and their relatives, conduct swatting, or claim to possess compromising material.

    The group denies those parts of the FBI’s characterization and has demanded that the bureau correct or remove them. BleepingComputer and CBS reported that ShinyHunters gave the FBI one week to do so. The group has described the action as nonfinancial and has rejected the FBI’s use of terms such as ransom, coercion, and extortion to describe its conduct.

    ShinyHunters told Reuters on Wednesday that it was trying to prevent the 5,000-record sample from circulating further and said it would not release more data at that time. The group has previously told Reuters that it obtained material related to employee and applicant vetting, contracted background investigations, and sensitive medical information, but Reuters has not verified what other records the group possesses.

    That uncertainty is significant given the group’s own stated data volume. Two to three terabytes would represent far more information than the spreadsheet reporters have reviewed, but there is currently no independent evidence confirming the size of the alleged collection. The same applies to the claim that the attackers obtained records covering almost every FBI employee and applicant.

    What Is Confirmed and What Is Still a Claim

    The strongest publicly supported facts are narrower than some of the early coverage suggested. The FBI is investigating ShinyHunters’ claim of a compromise involving FBIJobs.gov and possible employee PII exposure. ShinyHunters supplied journalists with thousands of records containing information that can be tied to real FBI and Justice Department personnel. Reuters has independently corroborated personal details for more than 22 individuals and career information for eight, and reporting from Reuters and 404 Media indicates that the dataset contains information associated with sensitive units and job functions.

    Reporting also indicates that FBIJobs.gov was disrupted following the incident. CBS reported that the application site and Special Agent Applicant Portal displayed a system-unavailable notice Tuesday, and The Record reported that ShinyHunters had replaced material on the site with imagery associated with the group. BleepingComputer published a screenshot supplied by ShinyHunters showing an alleged defacement. The FBI’s own September 23 statement does not independently confirm the defacement.

    Several larger claims remain open. There is no public confirmation that ShinyHunters stole two to three terabytes, obtained records on almost every FBI employee and applicant, reached the Criminal Justice Information Services environment, accessed MedLink, moved laterally across FBI-managed AWS GovCloud infrastructure, or used an undisclosed PeopleSoft zero-day. There is also no Oracle advisory or independent technical analysis confirming the new vulnerability claimed by the group as of September 24.

    The incident is serious without treating those unverified claims as established facts. A dataset already shown to contain genuine personnel information and apparent intelligence assignments can create privacy, operational-security, and counterintelligence risks on its own. What remains unknown is whether the 5,000-record sample represents the main exposure or a small portion of a far larger compromise.

    The next major development will likely come from forensic findings, a new FBI disclosure, or an Oracle security advisory. Until one of those surfaces, the safest assessment is that ShinyHunters has presented credible evidence that it obtained sensitive FBI-related personnel information, but the entry point, total scope, affected systems, and claimed PeopleSoft zero-day remain under investigation.

    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.

  • When Pull Requests Write Themselves, Code Review Has to Change

    When Pull Requests Write Themselves, Code Review Has to Change

    AI coding tools are changing far more than how quickly developers can produce code. They are changing the economics of the pull request itself. A pull request once represented a meaningful amount of authoring effort: a developer had to inspect the repository, make a set of changes, run tests, write a description, and submit the result for review. Coding agents can now perform much of that sequence from a single task.

    The scale of that change is already visible. Recent research on agent-authored development has documented hundreds of thousands of AI-generated pull requests across large numbers of public repositories, covering tools such as OpenAI Codex, GitHub Copilot, Cursor, Devin, and Claude Code. At that scale, agent-authored pull requests are no longer an experimental development practice. They are becoming part of normal software delivery, which creates a new problem for engineering teams: generating a candidate change is getting cheaper much faster than verifying one.

    The Bottleneck Moved Downstream

    AI lowers the cost of producing a plausible implementation, but it does not remove the cost of accepting responsibility for that implementation. A large diff may take an agent minutes to produce, yet a reviewer can still spend substantial time reconstructing its behavior, comparing it with existing architecture, checking side effects, validating tests, and deciding whether the team is prepared to maintain it months later.

    That changes how teams should think about productivity. A system that doubles the number of pull requests entering review does not necessarily double useful engineering output if reviewers become the limiting resource or if generated changes create more downstream maintenance work. The cost of authoring drops, but the cost of verification, operational responsibility, and long-term ownership remains.

    Research comparing agent-authored and human-authored pull requests has found measurable differences in commit count, files touched, and deleted lines. Agent-authored pull requests can also produce descriptions that closely match the underlying code changes. That may make generated contributions easier to read at first glance, but readability does not reduce the amount of system-level validation a reviewer still has to perform.

    Other research has found that agent-authored changes can be integrated faster in some cases but still receive lower merge rates overall. Outcomes also vary heavily by task type. Documentation work tends to be easier to validate than behavior-changing contributions, which argues against giving every AI-authored pull request the same review treatment. A documentation correction, a dependency change, and a new authorization path may all arrive through the same Git workflow, but their verification requirements are very different.

    Clean Code Can Still Be the Wrong Code

    AI-generated code often has a presentation advantage. It can arrive with consistent naming, clear comments, tests, documentation changes, and a carefully structured pull-request description. Those characteristics make a change easier to inspect, but they can also make it easier for a reviewer to accept local correctness without checking whether the change belongs in the wider codebase.

    Recent maintainability research on AI-generated pull requests has found that coding agents can miss opportunities to reuse existing code and instead introduce redundant implementations. At the same time, reviewers may react favorably to generated changes that look organized and complete. That combination creates a subtle review problem: a patch can appear clean while quietly recreating abstractions that already exist elsewhere in the repository.

    This type of defect is harder to catch than a syntax error or failing test. A new retry wrapper may behave correctly. A second date parser may be readable and fully tested. A generated HTTP helper may follow project style perfectly. The maintenance cost appears later, when parallel implementations drift apart, receive different fixes, or encode slightly different assumptions about error handling and policy.

    For that reason, review of AI-generated code needs to place more weight on repository-wide reuse. New validators, adapters, serializers, authorization checks, feature-flag utilities, retry logic, and client wrappers should trigger a search for existing equivalents. The reviewer is no longer asking only whether a function works. The more useful question is whether the function needed to be introduced in the first place.

    Passing Tests Carry Less Independent Weight

    Passing CI has never proven that a change is correct, but AI-generated pull requests make the limitation more obvious. The same system can write the implementation, generate the tests, update fixtures, modify configuration, and explain why everything is correct. If the agent misunderstood the requirement at the start, all of those artifacts can reinforce the same mistaken assumption.

    That creates correlated evidence. A generated test suite may provide strong evidence that the implementation behaves consistently with the tests the model created, but it does not independently prove that the implementation matches the real requirement. Reviewers need some evidence that comes from outside the same generation process, such as an existing regression test, a reproducible failure condition, externally defined acceptance criteria, a protocol specification, or observed behavior from the current production system.

    Reviewers should also inspect CI-related changes early, including workflow files, test configuration, coverage settings, skipped checks, and build scripts. A pull request can become green by changing the gate rather than correcting the underlying behavior. Generated changes can also introduce new tests that exercise only the path the agent expects to succeed, leaving boundary conditions and failure states untested.

    For bug fixes, a useful standard is to require a test or reproduction that demonstrates the failure before the fix and success after the fix. Feature changes can be handled in a similar way by tying tests to externally defined acceptance criteria. This gives the reviewer a stronger chain of evidence between the original problem, the generated patch, and the resulting behavior.

    Review Is Shifting From Syntax to Context

    Code-review tools are getting better at reading diffs, but repository context remains one of the harder problems for automated systems. Many serious review findings are not contained entirely inside the changed lines. They emerge from the relationship between the patch and a contract, policy, assumption, or dependency somewhere else in the system.

    Industrial research on LLM-based review agents has repeatedly identified missing context as a major limitation. A model may understand the changed file and still miss architectural assumptions elsewhere in the repository. Diff-focused analysis can identify obvious local mistakes, yet it has a harder time recognizing whether a seemingly reasonable change violates an existing system contract.

    That limitation maps closely to the failures experienced reviewers often spend the most time finding. A cache key can be valid within the changed file yet violate eviction assumptions elsewhere. A database query can return the expected rows but cross a tenancy boundary. A background task can work during normal execution but violate an idempotency requirement during retries. A new API field can be type-correct yet expose data that another service considers internal. A retry mechanism can look sensible in isolation while turning an upstream outage into a much larger traffic problem.

    AI-generated code raises the value of this type of review since language models are strong at producing locally coherent code. The reviewer increasingly needs to validate architecture, data flow, trust boundaries, failure behavior, compatibility, observability, and ownership rather than spending most of the review on formatting or basic implementation details.

    Security Review Needs to Follow Data and Authority

    Security review of generated code should focus on whether a change preserves the system’s existing trust model. Code that looks secure at the function level can still introduce a serious issue if it changes where authorization happens, how untrusted input flows through the application, or which component is allowed to make a security-sensitive decision.

    Recent studies comparing human- and AI-generated code have found different defect profiles between the two groups. AI-generated code can be simpler and more repetitive, yet researchers have also identified high-risk security flaws in generated samples. Those findings do not mean every generated patch is insecure. They show that AI-generated code can introduce recurring security failure patterns that deserve direct review attention.

    Large-scale studies of publicly attributed AI-generated code have also identified thousands of weakness instances across many CWE categories. The data varies by language, repository, and tool, so it should not be treated as a universal vulnerability rate. It does show that recognizable security defects are appearing at meaningful scale in AI-assisted code.

    For reviewers, the practical implication is to trace where untrusted data enters the application, where authorization decisions are made, where secrets cross process or service boundaries, and where a generated change introduces SQL execution, shell execution, deserialization, file access, network access, or new dependencies. Changes involving authentication, sessions, tenancy, permissions, and identity boundaries deserve particular scrutiny since a locally correct function can still violate a higher-level security invariant.

    Existing security mechanisms should also receive more trust than newly generated substitutes. If an agent creates its own sanitization routine instead of using the project’s established validation library, that difference should be questioned. The same principle applies to permission checks, cryptographic helpers, secret handling, and dependency selection. Generated code should fit the system’s existing security architecture rather than silently creating a second one.

    Having AI Review AI Does Not Solve the Problem

    The obvious response to higher volumes of generated pull requests is to use AI to review them. Automated review can absorb part of the workload, but recent benchmarking suggests that current systems still miss a substantial portion of the findings human reviewers identify.

    Recent pull-request review benchmarks built from real human review findings have shown that frontier models can identify some defects but still leave many issues undetected. Giving models more repository context does not always solve the problem either. Large context windows can introduce attention problems, making it harder for the model to determine which relationships matter most to the change under review.

    Those results reinforce an important distinction between code generation and code review. A model can be effective at producing a plausible patch from a specification and still perform poorly at finding subtle problems inside a completed change. Review requires adversarial thinking, architecture awareness, knowledge of system history, and an ability to recognize when code that appears correct violates an unstated assumption.

    Automated review still has a useful place in the pipeline. Static analysis, secret scanning, dependency analysis, unit tests, integration tests, policy checks, build gates, and AI-assisted review can all catch different categories of problems before a human gives final approval. Human reviewers can then spend more attention on architecture, security boundaries, system behavior, and whether the change matches the actual requirement.

    The better model is layered review rather than AI replacing human review. Deterministic tools can catch reproducible classes of defects. AI can flag suspicious patterns, missing tests, duplicated logic, and likely implementation mistakes. Human reviewers remain responsible for deciding whether the patch fits the system and whether the organization is prepared to own the resulting behavior.

    Provenance Becomes Part of Review Context

    Teams also need a clearer record of how a change was produced. Research on developer disclosure of AI-generated code shows that many developers report AI use at least some of the time, yet disclosure practices remain inconsistent. Some developers cite future review and debugging as reasons for recording AI involvement, which points to a practical use for provenance beyond simple transparency.

    Disclosure can be useful without becoming a quality label. Knowing that an agent produced most of a patch gives reviewers information about which failure modes deserve extra attention. Generated code may merit closer checks for duplicated abstractions, self-authored tests, unexpected CI changes, external API assumptions, configuration edits, new dependencies, or security-sensitive helpers.

    The most useful provenance record would go further than simply tagging a pull request as AI-generated. Teams can record which agent made the change, what task it received, what repository context it could access, which tools or commands it ran, which tests it executed, and how much human modification occurred before submission. That information gives future reviewers and incident responders a better picture of how the code entered the repository and what assumptions were present during generation.

    Smaller Pull Requests Matter Much More Now

    AI makes large changes cheaper to create, which makes pull-request size discipline more valuable. Human developers usually experience the cost of a large refactor during implementation. An agent does not face that same friction and can modify interfaces, create adapters, move files, add tests, change configuration, and update documentation in a single run.

    The resulting patch may be internally consistent and still be expensive for another person to verify. Review difficulty grows with the number of files, code paths, subsystems, and assumptions a reviewer has to hold in mind at once. Generated changes can reach that level much faster than human-authored work since adding another hundred lines carries almost no cost from the agent’s perspective.

    Teams can reduce this problem by constraining the task before generation. An agent can be instructed to make one behavioral change, stay within a defined file set, avoid unrelated refactoring, leave dependencies untouched without approval, and add tests directly linked to the requested behavior. If the agent discovers that the task requires a broader architectural change, that can become a separate pull request or engineering decision rather than being absorbed quietly into the original patch.

    This keeps the unit of generation closer to the unit a human can reasonably verify. That distinction becomes more important as agent throughput increases, since engineering capacity should be measured by the number of changes a team can confidently accept and maintain rather than the number of diffs an agent can produce.

    Code Review Is Becoming Verification Work

    AI-generated pull requests do not remove the need for code review. They change what reviewers need to spend their time reviewing. Formatting issues, boilerplate, simple implementation errors, and some categories of static defects can increasingly be handled before a human opens the pull request. The remaining work sits at a higher level of the system.

    Reviewers need to determine whether a patch solves the intended problem, uses the right existing abstractions, preserves architectural contracts, leaves CI meaningful, includes tests that provide real evidence, respects security boundaries, behaves correctly under failure, and creates a maintenance burden the team is prepared to accept. These are harder questions than checking naming or syntax, and they depend much more heavily on context.

    The central shift is that generated code is becoming cheap to propose but remains expensive to trust. As agents produce more pull requests, code review becomes less about cleaning up implementation details and more about validating whether a change deserves to become part of the system at all.

    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 (9/21/2026)

    Netizen: Monday Security Brief (9/21/2026)

    Today’s Topics:

    • ScreenConnect Flaw Turns a Trusted Remote Session Into a File Execution Path
    • Cisco ISE Zero-Day Turns an Identity Control Point Into Root Access
    • How can Netizen help?

    ScreenConnect Flaw Turns a Trusted Remote Session Into a File Execution Path

    Remote support software already occupies an unusually trusted position inside an enterprise. A technician can connect to endpoints, transfer files, interact with desktops, and perform administrative work from a single console. CVE-2026-84869 shows what can happen when the authorization checks surrounding those capabilities fail.

    ConnectWise disclosed the vulnerability on September 8, 2026, alongside the release of ScreenConnect 26.6.5. The flaw affects ScreenConnect versions prior to 26.6.5 and exists in the ScreenConnect client rather than the server. Under certain conditions, files can be transferred and executed through an active remote session without the authorization or Host confirmation that would normally control those actions. ConnectWise classified the issue as Priority 1 and assigned it a CVSS 3.1 score of 9.9.

    The CVSS vector explains why the flaw received a score just below the maximum. Exploitation can occur over a network, requires low privileges, has low attack complexity, and requires no interaction from the user on the affected endpoint. Successful exploitation can have high confidentiality, integrity, and availability impact. The changed-scope component is equally significant: activity initiated through one security context can affect the remote host on the other side of the ScreenConnect session.

    That distinction matters. CVE-2026-84869 is not a vulnerability that lets an unauthenticated attacker scan the internet and immediately compromise every ScreenConnect server they find. An active remote session is part of the attack path, and some level of privilege is required. The issue becomes dangerous once an attacker gains access to the session context needed to reach the vulnerable functionality. From there, a capability meant for legitimate remote administration can become a path for unauthorized file delivery and execution.

    CISA added CVE-2026-84869 to its Known Exploited Vulnerabilities Catalog on September 11 after receiving evidence of active exploitation. The agency listed September 14 as the remediation date for affected federal systems covered by its current vulnerability-management directive. CISA’s inclusion of the flaw moves it beyond theoretical severity: attackers are using the vulnerability against real systems. Public information does not currently establish a single threat group, malware family, or ransomware operation responsible for that exploitation.

    ScreenConnect is particularly valuable from an attacker’s perspective since remote-management software already has many of the capabilities an intrusion operator normally has to build or deploy. Legitimate administrators need remote desktop access, unattended endpoint access, file transfer, scripting, and software execution. If attackers can misuse those same mechanisms, their activity can travel through tooling an organization intentionally installed and trusted.

    This creates a different defensive problem from detecting an unknown remote-access trojan. A malicious executable appearing on a workstation may immediately attract endpoint attention. A legitimate management client carrying out file activity can be harder to judge without context. The security question shifts from whether ScreenConnect ran to who initiated the session, what permissions that identity should have had, what was transferred, where the file originated, and what executed after the transfer.

    CVE-2026-84869 also exposes why authorization controls inside remote-management products matter as much as authentication at the front door. Multi-factor authentication, credential protection, and account monitoring can make account takeover more difficult, but they cannot compensate for a sensitive action that fails to check whether an authenticated session is permitted to perform it. ConnectWise classified the issue under both missing authorization and improper privilege management, reflecting that separation between gaining access to a session and being allowed to perform a privileged operation inside it.

    ConnectWise patched the behavior in ScreenConnect 26.6.5 by changing client and session handling around file-transfer and file-execution actions. Cloud customers receive the server-side update through the hosted service, but ConnectWise directs customers to reinstall Host clients and update Access agents after the upgrade. On-premises customers need to install version 26.6.5 or later. Systems running older clients remain part of the exposure that administrators need to address.

    Organizations that cannot patch an on-premises deployment immediately have a temporary option. ConnectWise recommends reviewing ScreenConnect roles and removing the TransferFiles permission from each applicable session group. The company states that this measure only reduces exposure and does not replace the security update. That distinction is worth retaining during emergency change windows: limiting file transfer closes part of the reachable functionality, but the supported fix is still the updated client behavior.

    Defenders should also treat the disclosure as a reason to examine ScreenConnect activity retrospectively rather than stopping at version inventory. CISA’s KEV listing confirms exploitation has occurred. Organizations with exposed or heavily used ScreenConnect environments can review session history, technician identities, unusual access times, unexpected file transfers, processes launched shortly after remote sessions, and endpoint telemetry tied to ScreenConnect client activity. The value comes from correlating management-plane records with endpoint and network data rather than treating any single log source as complete.

    CVE-2026-84869 is a useful example of a broader problem surrounding remote administration. Security teams often focus on preventing attackers from deploying their own tools. Modern intrusions do not always require that step. If an attacker can acquire access to a trusted management platform and reach a weak authorization boundary inside it, the organization may already provide much of the remote execution infrastructure the attacker needs.

    For ScreenConnect customers, the immediate response is direct: move affected deployments to 26.6.5 or later, refresh the relevant clients and agents, and review recent remote-session activity for signs of misuse. The longer-term lesson reaches beyond one product. Remote-management systems sit close to the endpoints they administer and often carry privileges that few other applications possess. Their internal authorization boundaries deserve the same scrutiny organizations place on identity providers, privileged-access systems, and other administrative control planes.

    Cisco ISE Zero-Day Turns an Identity Control Point Into Root Access

    Cisco Identity Services Engine exists to make access decisions. It helps organizations determine which users and devices can connect, apply policy, and control access across enterprise networks. A newly disclosed zero-day creates the opposite situation: an unauthenticated attacker can bypass authentication to the platform itself and, after successful exploitation, potentially reach root-level command execution.

    Cisco disclosed CVE-2026-76460 on September 16, 2026. The vulnerability affects Cisco ISE and Cisco ISE Passive Identity Connector deployments regardless of configuration. Cisco assigned the flaw a CVSS 3.1 score of 10.0, with network-based exploitation, low attack complexity, no required privileges, and no user interaction. The advisory supplied with the research material confirms the same affected-product scope and maximum base score.

    The vulnerability stems from insufficient authentication control on an API endpoint. According to Cisco, an attacker can send a crafted request to an affected endpoint and bypass the web-based management interface. That alone would make the issue serious for a network-access-control platform. Cisco’s incident-response guidance raises the potential impact further: successful exploitation can give the attacker command execution with root privileges.

    Cisco has confirmed active exploitation. CISA added CVE-2026-76460 to its Known Exploited Vulnerabilities Catalog on September 16, setting September 19 as the remediation date for affected federal assets covered by its directive. The vulnerability was not uncovered through a routine researcher submission. Cisco states that it found the issue during work on a Technical Assistance Center support case, a detail that fits with exploitation having already occurred before public disclosure.

    ISE is a high-value target for reasons that extend beyond the appliance itself. The platform can sit at the center of enterprise authentication and network-access policy, integrating with switches, wireless infrastructure, identity stores, endpoint posture systems, and administrative workflows. Compromise of such a system places an attacker inside a management layer that organizations use to decide which systems should be trusted in the first place.

    That makes CVE-2026-76460 different from a vulnerability affecting a less privileged application server. An attacker reaching root on ISE gains control of the underlying device at the same point defenders rely on it for identity and policy enforcement. Cisco warns that an attacker with this level of access may remove or conceal evidence of exploitation. Local logs on a compromised node cannot automatically be treated as a complete record of what occurred.

    Cisco has published a practical starting point for compromise assessment. Administrators can review the ISE Kong API gateway access log for suspicious usernames and repeat that review across every node in a distributed deployment. Cisco also recommends collecting the wider API gateway logs through a support bundle for further investigation. Entries involving unexpected usernames may indicate attempted exploitation, though the vendor makes clear that the example it provides is not an exhaustive indicator.

    The harder part begins after suspected exploitation. Root access gives an intruder the ability to interfere with the same local telemetry investigators would normally use to reconstruct the incident. Cisco tells administrators to cross-check logs that reside outside the affected appliance, including firewall and network records, for suspicious connections, unexpected uploads from the ISE system, or downloads from malicious infrastructure. If malicious activity is suspected, Cisco recommends re-imaging affected nodes and restoring configuration from backup rather than trusting the existing installation.

    That guidance demonstrates a core incident-response principle for privileged infrastructure. Once an attacker has reached the highest operating-system privilege level, remediation becomes a trust problem rather than a simple malware-removal problem. Investigators need telemetry that the compromised system could not alter and a recovery process that returns the appliance to a known state.

    Cisco says there is no workaround that resolves CVE-2026-76460. Administrators can use infrastructure access control lists to restrict management and control-plane traffic destined for affected devices, which can reduce opportunities for remote exploitation. Cisco still treats that step as a mitigation rather than a fix.

    The fixed versions depend on the ISE branch in use. Cisco lists 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7, and 3.5 Patch 4 as the first releases containing the correction. ISE 3.0 has already reached the end of software maintenance, so deployments on that branch need to move to a supported release containing the fix.

    The timing of CVE-2026-76460 also places it inside a much larger September security release for ISE. Cisco published a hardening package addressing multiple vulnerability classes across ISE and ISE-PIC, including input-validation, privilege-management, authorization, injection, and related security issues. Cisco states that the authentication bypass is the flaw from that group known to be under active exploitation.

    For organizations running ISE, patching is only one part of the response. Systems that were reachable before the update merit log review and compromise assessment, especially given the confirmed exploitation and possibility of root access. Management interfaces should also be reachable only from systems and network segments that have a legitimate administrative need to contact them.

    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.

  • What an SBOM Can Miss

    What an SBOM Can Miss

    A Software Bill of Materials can answer one of the hardest questions in software security: what is actually inside this product? That answer has real operational value. When a new vulnerability appears in a widely used library, an SBOM can help an organization determine which applications contain the affected component without manually inspecting every product. It can expose transitive dependencies developers did not knowingly select and support vulnerability response, procurement, licensing, and software supply-chain analysis.

    CISA’s 2025 minimum elements for SBOMs reflect how much the concept has matured. The agency states that an SBOM should cover the components that make up the target software, including transitive dependencies, with no minimum dependency depth. CISA also states that incomplete dependency information should be identified as a known unknown rather than silently omitted. That level of transparency can give security teams a far better starting point for evaluating software than a product name and version alone.

    The limitation is that software inventory and software security are not the same thing. An SBOM describes components and relationships, but it does not independently prove that every component was identified correctly, that the build process was trustworthy, that a listed vulnerability is exploitable in the deployed product, or that an unlisted vulnerability does not exist. NTIA made a similar distinction in its original minimum-elements work by describing SBOM data as a foundational layer for software transparency rather than a complete answer to software security.

    That distinction becomes much more significant once organizations begin using SBOM data to prioritize remediation or make decisions about software risk.

    An Inventory Can Be Wrong

    The first limitation is accuracy. An SBOM provides useful security information only when the component inventory accurately represents the software it describes. A missing dependency can prevent a vulnerability-management platform from identifying an affected application, and an incorrectly listed dependency can create false positives that consume analyst time.

    Research presented at NDSS 2025 tested this problem at scale through the JBomAudit project. Researchers examined 25,882 developer-published Java SBOMs alongside their associated JAR files and found that 7,907 SBOMs failed to disclose direct dependencies. Of the omitted dependencies, 4.97 percent contained known vulnerabilities. In those cases, a vulnerability scanner relying entirely on SBOM data could miss real exposure even if the scanner itself worked exactly as intended.

    The problem comes partly from how SBOMs are generated. Tools can inspect package manifests, lock files, compiled artifacts, container images, build environments, or installed packages. Those approaches do not always produce identical results. A 2024 analysis of four SBOM-generation tools in the Python ecosystem found inconsistencies involving package versions, optional dependencies, remote dependencies, and package metadata. The researchers described complete and correct SBOM generation as an area that still requires improvement.

    CISA’s 2025 guidance reflects that concern by stating that SBOM errors should be corrected after discovery and revised SBOMs should be generated when new information becomes available. A document can follow the correct machine-readable format and still contain an incomplete or inaccurate description of the software.

    Component Presence Does Not Equal Exploitability

    A second limitation appears once an SBOM successfully identifies a vulnerable component. The presence of a vulnerable library does not automatically mean the final application exposes the vulnerable behavior.

    A library may provide hundreds of functions even though the application calls only a small subset. A vulnerable feature may never execute, an affected module may be excluded from the production configuration, or a dangerous code path may require conditions that are absent from the deployed environment. CISA’s software component transparency guidance discusses this distinction by noting that downstream software can include an upstream component without using every part of that component.

    This is one reason Vulnerability Exploitability eXchange, or VEX, exists alongside SBOMs. VEX can communicate whether a product is considered affected, not affected, fixed, or still under investigation for a particular vulnerability. CISA’s SBOM consumption guidance notes that vulnerability matches derived from component inventories can overstate product risk and describes VEX as one mechanism for improving prioritization.

    Log4Shell demonstrated the practical value of this distinction. Finding Log4j inside an application was an important first step, but defenders still needed information about versions, application behavior, exposed interfaces, configuration, deployment context, and compensating controls. The SBOM could help establish component presence, but further analysis was still required to determine actual exposure.

    A mature vulnerability-management process should use the SBOM as one source of evidence rather than treating every component-to-CVE match as an equivalent security finding.

    An SBOM Does Not Prove the Build Was Clean

    Component inventory also says little about the integrity of the process that produced the final artifact. Two binaries can contain the same dependencies yet originate from very different build environments.

    One might be compiled from reviewed source code through an approved CI/CD pipeline using controlled dependencies. Another might be built after an attacker compromises the build infrastructure and injects malicious code shortly before packaging. Their component inventories could remain very similar despite a major difference in trust.

    OpenSSF has addressed this gap through its work on attestations. Traditional SBOMs describe software composition, but they do not inherently prove how an artifact was built, tested, or deployed. Signing an SBOM can help establish who produced the document and whether it was modified later, but the signature alone cannot establish the integrity of the build process that created the software.

    Frameworks such as SLSA use provenance attestations to provide that missing context. Build provenance can document where an artifact came from, what source was used, and which build environment produced it. SBOM information and provenance answer related but separate security questions, and organizations gain more useful supply-chain visibility when they can correlate both.

    This becomes particularly relevant during incidents involving compromised CI/CD systems, malicious build actions, or unauthorized changes introduced after normal source-code review. A dependency inventory may remain accurate even when the artifact itself should no longer be trusted.

    Known Components Can Still Contain Unknown Threats

    SBOM-driven vulnerability management also depends heavily on information that defenders already possess. It works particularly well after a component or version has been associated with a known vulnerability. It provides much less information before researchers identify the problem.

    The XZ Utils compromise in 2024 illustrates that limit. Malicious code associated with XZ Utils versions 5.6.0 and 5.6.1 was introduced through a supply-chain compromise rather than an ordinary accidental programming flaw. After disclosure, organizations with accurate SBOM inventories could search for the affected versions and identify systems that required investigation.

    Before discovery, those same component entries could have appeared normal. An SBOM identifying XZ Utils 5.6.1 could correctly report the component name, supplier, version, and integrity information without determining that the release contained intentionally malicious behavior.

    Analysis of the XZ incident also found that parts of the malicious behavior depended on release artifacts and the build process rather than presenting themselves as a simple malicious source file. That distinction reinforces why software composition data works best alongside provenance, artifact verification, behavioral analysis, and threat intelligence.

    An accurate inventory can identify what software is present, but determining whether that software itself is trustworthy requires other forms of evidence.

    Runtime Can Change the Dependency Picture

    Software does not always finish assembling itself during the build process. Applications can download plug-ins, retrieve modules, install packages, connect to external APIs, load operating-system libraries, or change behavior according to configuration and user input. These relationships can be difficult to capture through a static build-time SBOM.

    Cloud and SaaS environments make this problem more visible. A traditional application package may have a relatively stable collection of files and dependencies, but a SaaS platform can change continuously and rely on external services that the customer never installs or directly manages. CISA’s 2025 SBOM minimum-elements guidance identifies cloud software, SaaS, AI systems, validation, and correlation with security advisories as areas that still require further work.

    CISA’s separate work on software transparency in SaaS environments also discusses service dependencies. One application can depend on an external service, which itself relies on other platforms and services. Those relationships can create a supply chain that extends well beyond the libraries compiled into the original product.

    CycloneDX has developed a SaaSBOM model that can describe service endpoints, service dependencies, data flows, and classifications. Models such as this expand software transparency beyond traditional package inventories and recognize that application dependencies increasingly include remote services in addition to local software components.

    For defenders, this means a conventional SBOM can provide an accurate description of packaged software without providing a complete description of everything the application relies on during normal operation.

    Deployment Configuration Changes the Risk

    Software composition also lacks much of the environmental context required for risk analysis. Two organizations can deploy the same application with identical dependencies and face very different levels of exposure.

    One organization might expose a vulnerable administrative interface directly to the internet. Another might disable that interface. A third could place it behind an identity-aware proxy and restrict access to administrative networks. The component inventory may remain identical across all three environments, but the attack paths are materially different.

    The same issue applies to optional modules, database connectors, APIs, operating-system libraries, cryptographic functions, and management interfaces. Security risk depends on factors such as network exposure, enabled functionality, process privileges, available identities, segmentation, and surrounding controls.

    NIST’s software supply-chain guidance recommends combining SBOM information with other organizational and asset data rather than evaluating it in isolation. Integration with vulnerability-management systems, asset inventories, deployment information, and security controls can help an organization determine where an affected component is actually running and how exposed it is.

    An SBOM becomes more operationally useful once its component records can be associated with real systems, applications, environments, and owners.

    An Old SBOM Describes Old Software

    Accuracy also degrades over time. An SBOM describes a particular software state, but software changes through dependency updates, container rebuilds, plug-in installations, emergency patches, and normal CI/CD activity.

    CISA’s updated minimum-elements guidance states that each software version or update should have an associated SBOM and that builds containing changed dependencies should produce new SBOM data. This turns SBOM management into an ongoing lifecycle process rather than a document that can be generated once during procurement and stored indefinitely.

    The operational challenge is correlating the correct SBOM with the software that is actually running. An organization might maintain ten SBOMs for ten application versions but still struggle to identify which version is deployed on a particular server or endpoint. In that situation, the component data may be accurate without providing useful answers during vulnerability response.

    Effective SBOM consumption depends on asset management. Security teams need to connect software composition records with deployed artifacts so a newly disclosed vulnerability can be traced from the affected component to the systems that actually contain it.

    Valid Formatting Does Not Prove Completeness

    SBOM standards such as SPDX and CycloneDX provide consistent ways to represent software component information in machine-readable formats. Format validation can confirm that required structures, fields, and relationships follow the selected schema.

    That validation does not independently prove that the inventory is complete.

    The NDSS JBomAudit research illustrates the distinction. The researchers analyzed developer-published SBOMs rather than random malformed dependency lists, yet thousands still omitted direct dependencies found in the associated software artifacts. The existence of a valid SBOM did not prove that the inventory contained everything defenders needed to know.

    Organizations evaluating supplier SBOMs need more context about how the documents were created. Useful questions include which generation method was used, whether the finished artifact was analyzed, whether transitive dependencies were included, how unresolved components are represented, and how revised SBOMs are distributed after software changes.

    CISA’s 2025 guidance places greater weight on this issue by calling for transitive dependency coverage and explicit identification of gaps. Those requirements can improve transparency, but organizations still need processes for assessing the quality of the data they receive.

    SBOM adoption becomes much less meaningful if success is measured only by whether a supplier delivered a file.

    AI and SaaS Are Stretching the Definition of a Component

    AI-enabled applications are also forcing software security teams to reconsider what should count as a component. A modern AI application can depend on conventional software libraries, machine-learning frameworks, model weights, external inference services, retrieval databases, plug-ins, vector stores, datasets, and external tools.

    A traditional SBOM format may describe the software packages involved without capturing every model, service, or data dependency relevant to the system’s risk. CISA’s 2025 minimum-elements document identifies AI software as an area where the existing model may require further data fields and component types.

    SaaS introduces a related issue. An application might depend on an external identity provider, payment processor, analytics platform, content-delivery service, messaging provider, and several APIs. Those services may be operationally important to the product without ever appearing as packages inside its binary or container.

    This does not make the existing SBOM model obsolete. It means organizations need to recognize that software composition increasingly includes relationships that extend beyond the contents of a build artifact.

    Large Inventories Still Need Security Context

    Another problem appears once SBOM adoption succeeds at scale. A large organization can collect millions of component records across thousands of products and then match those records against vulnerability databases. The resulting number of findings can become difficult to prioritize.

    Some vulnerability matches represent directly exposed and actively exploitable software. Others may involve unused code paths, development-only packages, disabled functionality, systems protected by compensating controls, or versions that are no longer deployed. Ambiguous software identifiers can also create incorrect matches.

    CISA and international partners addressed this issue in their 2025 shared vision for SBOM use. Their guidance describes SBOM information as data that should be correlated with vulnerability databases, security advisories, supply-chain information, project data, end-of-support information, and VEX records.

    That correlation is what turns component inventory into risk information. An organization gains much more from knowing which vulnerable component is running on an internet-facing production system than from knowing that the same component name appears somewhere in a repository of historical SBOMs.

    The maturity of an SBOM program should be measured by the quality of decisions the data supports rather than by the number of SBOM files collected.

    Treat the SBOM as Evidence, Not the Entire Answer

    These limitations do not diminish the value of SBOMs. They define where SBOMs fit within a larger software supply-chain security program. Accurate component inventories can dramatically reduce the time required to investigate newly disclosed vulnerabilities, reveal dependencies developers did not knowingly select, identify unsupported software, and expose concentrations of dependency risk across an organization.

    Their value increases when component information is correlated with other evidence. VEX can provide exploitability context, provenance attestations can document build history, vulnerability intelligence can identify known flaws, runtime telemetry can show actual application behavior, and asset inventories can connect software components to deployed systems.

    Taken together, those sources answer a much broader set of questions than an SBOM can answer alone. Security teams can determine which components exist, where they are deployed, whether affected code is reachable, how the artifact was produced, and what controls surround the application.

    Software transparency gives defenders an important starting point for supply-chain security. The mistake is treating component identification as the end of the analysis. An SBOM can make software risk far easier to investigate, but the quality of that investigation still depends on the context surrounding the inventory.

    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.

  • Ransomware Gangs Are Going After the Recovery Plan

    Ransomware Gangs Are Going After the Recovery Plan

    Ransomware used to create a fairly direct technical problem: attackers encrypted production data, defenders restored it, and the organization tried to resume operations. Modern ransomware crews have spent years attacking that equation. Rather than leaving recovery infrastructure untouched, operators increasingly target backup systems, virtualization platforms, identity services, storage, snapshots, recovery documentation, and the administrative accounts needed to rebuild an environment.

    Google Threat Intelligence Group describes this change as a shift toward “recovery denial.” In its 2026 M-Trends reporting, Google said ransomware operators observed during 2025 actively targeted backup infrastructure, identity services, and virtualization management planes. The activity included groups associated with Akira and Qilin, along with attacks that deleted cloud backup objects or abused identity infrastructure to maintain privileged access.

    The objective is straightforward. Encryption creates disruption. Destroying the victim’s ability to restore creates leverage.

    Recovery Is Becoming Part of the Target

    Backup infrastructure used to sit near the end of the defensive conversation. Security teams tried to keep ransomware away from production systems, then relied on backups if prevention failed. That model assumes the attacker treats recovery systems as neutral territory.

    Current incident data shows the opposite. Veeam’s 2025 ransomware research surveyed 1,300 organizations, including 900 that had experienced at least one ransomware incident during the prior year. Veeam later reported that 89 percent of organizations in its study had backup repositories targeted by attackers. As with any vendor survey, that percentage represents the surveyed population rather than every ransomware incident, but it illustrates how routine attacks against backup infrastructure have become.

    CISA has warned about the same tactic for years. Its StopRansomware guidance states that many ransomware variants search for accessible backups and attempt to delete or encrypt them so restoration becomes impossible. CISA recommends offline, encrypted backups and regular tests of backup availability and integrity.

    The shift changes the security question. It is no longer enough to ask whether data is backed up. Organizations need to ask whether those backups remain accessible after an attacker gains privileged access to the rest of the environment.

    Backup Servers Are More Than Storage

    A backup server can hold far more value than the data inside its repositories.

    Backup platforms frequently need broad access across an enterprise. They connect to servers, databases, virtual machines, storage systems, hypervisors, and cloud workloads. They may contain service accounts or stored credentials that allow those connections to function. From an attacker’s perspective, that can turn a backup platform into a source of privilege rather than merely something to delete.

    Google’s 2026 analysis of ransomware activity found that threat actors targeted Veeam Backup & Replication for credential harvesting in roughly 10 percent of the intrusions it examined. Attackers used tools such as Veeam-Get-Creds.ps1 and custom PowerShell scripts to retrieve credentials stored in Veeam configuration data.

    That creates an uncomfortable reversal. A product deployed to protect critical systems may also maintain trusted relationships with many of those systems. Once an attacker controls it, the same connectivity that supports backup operations can help reveal credentials, infrastructure relationships, storage locations, and recovery architecture.

    This is why backup infrastructure needs its own administrative boundary. A backup console managed by the same accounts used across ordinary production infrastructure can inherit the compromise of those accounts.

    Delete the Safety Net Before Encryption Starts

    Some crews attack backup infrastructure manually before ransomware deployment.

    Google’s investigation of UNC3944 provides a clear example. After gaining broad control of an Active Directory environment, the actor targeted virtualized backup infrastructure. Google documented the use of compromised Domain Admin credentials to access a backup server and another path in which attackers added an account they controlled to the Veeam Administrators group in Active Directory.

    From there, the actor could delete backup jobs, snapshots, and repositories before ransomware deployment. Google described this stage as “Backup Sabotage” and recommended separating backup infrastructure from the normal Active Directory trust relationship, using dedicated credentials, restricting administrative access, and deploying immutable repositories.

    The sequence matters.

    By the time encryption becomes visible, the recovery environment may already be damaged. Alerts tied only to the ransomware executable arrive near the end of the intrusion. The events that determine whether the organization can recover may have happened hours earlier through administrative logins, group membership changes, repository deletions, retention changes, or storage operations that looked legitimate at the protocol level.

    Ransomware defense needs to detect attacks against the recovery process before the encryptor appears.

    Some Ransomware Tries to Shut Recovery Down Automatically

    Recovery disruption is also built directly into modern ransomware.

    In May 2026, Microsoft published a technical analysis of the Gentlemen ransomware family. The malware contains extensive process and service termination routines aimed at virtualization software, databases, endpoint security products, remote-access tools, and backup systems.

    Among the targeted processes were VeeamNFSSvc, VeeamTransportSvc, VeeamDeploymentSvc, Iperius backup components, Commvault components, and VSS-related services. The service termination list included Veeam, Acronis, Backup Exec, Commvault, Volume Shadow Copy services, and other storage or recovery products.

    Microsoft identified two reasons for the behavior. Stopping applications can release file locks and increase encryption coverage. Stopping security and backup services also interferes with detection and recovery.

    That distinction matters. A stopped database service may help the ransomware encrypt a database file. A stopped backup service helps make sure defenders have fewer options after the encryption finishes.

    The malware is attacking both the data and the process used to get the data back.

    Hypervisors Turn One Compromise Into Mass Impact

    Virtualization infrastructure has become another major pressure point.

    Google reported that threat actors targeted virtualization infrastructure in nearly 20 percent of the ransomware incidents it examined from 2025. In one UNC5495 intrusion, an actor automated deployment of a Babuk ransomware variant against ESXi hosts using a batch script and SSH. In another incident, attackers used PowerShell to authenticate to vCenter, set new ESXi root passwords, enable SSH, transfer ransomware, delete backups, shut down virtual machines, disable security policies, and then run the encryptor.

    The attraction is clear. Compromising an individual virtual machine affects one workload. Compromising the hypervisor can affect many workloads at once.

    Microsoft documented the same trend in its research into CVE-2024-37085, an ESXi authentication vulnerability exploited by ransomware operators. Microsoft said its incident-response engagements involving attacks against ESXi hypervisors had more than doubled across the preceding three years. Groups and affiliates associated with Akira, Black Basta, Babuk, LockBit, and other ransomware families had developed or used ESXi encryption capabilities.

    In one Black Basta intrusion described by Microsoft, the attackers compromised domain administrator accounts, created an “ESX Admins” group, gained administrative access to ESXi, and encrypted the hypervisor file system. The hosted virtual machines lost functionality as a result.

    This is one reason hypervisors belong in the same defensive conversation as domain controllers and backup servers. They are concentration points. A single privileged action can affect dozens of systems that would otherwise require individual compromise.

    Identity Can Break Recovery Before the Backups Are Touched

    Recovery infrastructure still depends on identity.

    Backup administrators need accounts. Hypervisor administrators need accounts. Cloud recovery vaults have roles and permissions. Storage systems accept administrative credentials. Recovery teams need access to documentation, consoles, encryption keys, and configuration data.

    If all of those paths depend on the same identity system that the attacker already controls, the recovery environment may fail without a single backup file being encrypted.

    Google’s M-Trends 2026 reporting described ransomware actors targeting identity services alongside backup and virtualization infrastructure. Researchers observed misuse of Active Directory Certificate Services configurations to create privileged access that could survive ordinary password rotation.

    The UNC3944 activity shows the same relationship at a smaller scale. Compromised Active Directory privileges were used to gain control over Veeam administrative access. Production identity and recovery identity had become part of the same attack path.

    Separating those trust relationships can materially change an attack. Google recommends placing backup infrastructure in a separate security domain or using dedicated credentials that are not joined to the normal Active Directory environment. Microsoft recommends out-of-band controls such as MFA or a separate PIN before permitting destructive changes to online backups.

    The goal is to stop one compromised administrator account from becoming an administrator account for everything.

    Immutability Changes What an Attacker Can Destroy

    Immutable storage has become one of the strongest technical controls against recovery denial.

    An immutable recovery point cannot be changed or deleted during its retention period, including by an account that normally has administrative access. That creates a security property very different from a traditional backup repository where an attacker with administrator credentials may be able to delete the data.

    Microsoft’s 2026 ransomware-resilient backup architecture recommends immutability and soft-delete controls so compromised administrators cannot purge recovery points during the protected retention window. Microsoft also recommends separation between recovery copies to reduce the chance that a single administrative compromise destroys every usable copy. Immutability does not solve every recovery problem.

    Veeam’s review of cyber-extortion cases from 2025 reported that attackers had moved beyond simple backup deletion into tampering with backup configurations, policies, schedules, and backup objects. Some forms of sabotage might not become apparent until the organization attempts a restore. Veeam argues that recovery confidence depends on the integrity of the management and identity paths around the backup system, not just whether the backup blocks themselves are immutable.

    An immutable copy can preserve data. It cannot rebuild a broken identity system, reconstruct undocumented dependencies, replace compromised credentials, or tell responders which recovery point is clean. That is the gap between having a backup and having a recovery capability.

    A Backup Is Not a Recovery Plan

    Successful recovery depends on more than copying files back into production.

    CISA recommends regular disaster-recovery testing, offline copies, golden images for critical systems, and protected infrastructure-as-code templates that can be used to rebuild environments. It also warns responders to avoid reconnecting infected systems to clean recovery networks.

    Microsoft goes a step further by calling out the supporting information needed during restoration. Its ransomware recovery guidance recommends protecting recovery procedures, configuration-management data, network diagrams, and other documentation from the same attacker that is targeting production and backups. Microsoft states that attackers may deliberately target those materials to interfere with restoration. That point is easy to overlook.

    A recovery runbook stored on the same domain file server that gets encrypted is not a reliable runbook. A network diagram available only through the compromised identity provider may not be available during the incident. A password vault that depends on unavailable authentication infrastructure can create another dead end. A backup of an application is less useful if nobody has documented its databases, service accounts, certificates, dependencies, DNS records, network rules, and restoration order.

    A meaningful recovery test needs to prove that the organization can rebuild under hostile conditions rather than ideal ones.

    Clean Recovery Is a Separate Security Problem

    There is also a danger in restoring too quickly.

    If attackers maintained persistence for days before encryption, a recent backup may contain artifacts from the intrusion. Rebuilding a server from that recovery point could restore attacker-created accounts, malicious scheduled tasks, web shells, remote-management tools, altered configurations, or other persistence mechanisms.

    CISA explicitly warns organizations to avoid reinfecting clean systems during restoration and recommends isolating recovery environments so only verified systems are introduced.

    Veeam’s 2026 analysis of cyber-extortion cases makes a similar point. Recovery needs to account for attacker persistence, compromised credentials, malware, and damaged backup configurations rather than treating restoration as a simple data-copy operation. This is where incident response and disaster recovery become the same problem.

    The security team needs to establish what the attacker touched. The infrastructure team needs to determine what can be trusted. Identity teams need to rotate or rebuild compromised credentials. Backup teams need to identify clean recovery points. Network teams need isolation for restored systems. Application owners need to validate functionality before those systems reconnect to production. Restoration without that coordination can return the organization to an earlier version of the compromise.

    Recovery Infrastructure Needs Detection Engineering Too

    Backup and virtualization environments often receive far less detection coverage than Windows endpoints and domain controllers. That needs to change.

    Google’s UNC3944 analysis gives defenders several concrete signals. An interactive logon to a backup server by an unexpected privileged account can appear in Windows Event ID 4624. Adding a user to a privileged security group such as Veeam Administrators can generate Event ID 4728. Backup audit logs can expose mass deletion of jobs, snapshots, or repositories.

    Hypervisor activity creates another detection layer. Microsoft recommends forwarding ESXi logs into SIEM infrastructure and monitoring unexpected administrative access.

    Security teams can extend that idea across the recovery estate. Changes to immutability settings, retention periods, backup schedules, repository configuration, cloud recovery vaults, storage snapshots, hypervisor SSH access, vCenter administrators, service accounts, recovery roles, or backup encryption keys all deserve security telemetry.

    The same is true for failed recovery controls. A backup job that unexpectedly stops running may be an operational problem. Ten critical backup jobs disabled within minutes of a privileged login may be an incident.

    Detection engineering should treat destructive changes to recovery infrastructure with the same seriousness as changes to identity or endpoint security controls.

    Make Recovery Harder to Reach Than Production

    The safest recovery architecture assumes an attacker may gain control of the production environment.

    From that assumption, several design decisions follow. Backup administrators should have separate credentials. Destructive operations should require stronger authentication. At least one recovery copy should resist deletion through immutability, offline storage, or another isolated mechanism. Hypervisors and backup consoles need dedicated monitoring. Recovery documentation needs to remain available after the primary identity and file-storage systems fail. Restore procedures need to be tested under conditions that resemble an actual breach.

    CISA and Microsoft both stress that backups need isolation and regular recovery testing rather than simple confirmation that backup jobs completed successfully. Modern ransomware makes that distinction necessary.

    The attacker may have the Domain Admin account. They may have vCenter. They may know where Veeam is installed. They may have disabled backup services, deleted snapshots, changed retention settings, reset hypervisor credentials, and encrypted production systems by the time the ransom note appears.

    At that point, the organization’s security depends on whether something survived outside the attacker’s administrative reach.

    Ransomware crews have learned that the fastest route to payment is not always encrypting more data. Sometimes it is making sure the victim has nowhere clean to restore it from.

    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.

  • Does Your Browser Know Too Much?

    Does Your Browser Know Too Much?

    A web browser no longer acts as a simple viewer for websites. For many employees, it has become the front door to email, cloud storage, source code, HR systems, identity portals, banking, collaboration platforms, AI tools, and administrative consoles. The same browser may store passwords, maintain authenticated sessions, remember payment data and addresses, sync history and tabs across devices, load third-party extensions, and keep permissions for cameras, microphones, location, notifications, and local files. That concentration of information makes the browser one of the most sensitive applications on a modern endpoint.

    The threat is current, not theoretical. On September 3, 2026, Google released a Chrome update that fixed 12 security flaws, including CVE-2026-85046, a high-severity type-confusion flaw in the V8 JavaScript engine. Google said an exploit for the vulnerability existed in the wild. A browser flaw does not automatically give an attacker every secret in a browser profile; sandboxing and other security boundaries still matter. The event still shows why browsers receive constant attention from attackers: they parse untrusted content all day and sit beside some of the most valuable authentication material on the device.

    The Browser Has Become an Identity Store

    The data stored by the browser has changed. A password used to be the obvious prize. Today, an authenticated session can be just as useful. After a user completes a password prompt and MFA challenge, many services issue session cookies or tokens so the user does not need to authenticate on every request. If malware steals a reusable session token, an attacker may be able to replay the authenticated state from another machine until the token expires, is revoked, or is rejected by an extra control. Microsoft warns that a stolen token can let an attacker impersonate a victim until that token is no longer valid.

    Google describes session theft in similar terms. Its 2026 rollout of Device Bound Session Credentials, or DBSC, was built to reduce the value of stolen browser cookies by tying protected sessions to hardware-backed keys. Google says infostealers can silently extract existing session cookies or wait for new logins, then send those tokens to attacker infrastructure. The company also states that stolen cookies can grant account access without the attacker needing the victim’s password. DBSC entered public availability for Windows users in Chrome 146 in April 2026, with protected services issuing short-lived cookies that depend on proof from a non-exportable device key.

    Session Cookies Can Be More Valuable Than Passwords

    That defensive investment exists for a reason. Unit 42 reported that social engineering accounted for 36 percent of the incident-response cases it examined between May 2024 and May 2025. In ClickFix campaigns, Unit 42 observed commodity stealers such as RedLine and Lumma being used to collect browser-stored credentials, saved tokens, and session cookies after users ran malicious installers or commands. The malware is interested in the browser as a container for identity, not just as a piece of software.

    Chrome has been hardening that container. In Chrome 127, Google introduced App-Bound Encryption on Windows, initially for cookies. The feature ties encrypted browser data to Chrome’s application identity so another application running as the same Windows user cannot simply call the same decryption path. Google stated that bypassing this protection pushes malware into noisier techniques such as privilege escalation or code injection into Chrome. Google also documented event-log signals that defenders can use to identify attempts to decrypt Chrome-protected data from another application.

    Attackers adapted. Proofpoint reported in 2025 that variants related to Stealerium used Chrome’s remote-debugging feature as a way to extract browser data. Proofpoint observed the browser being launched with a remote-debugging argument and described the method as one used by infostealers to get around browser protections, including App-Bound Encryption, and reach cookies or credentials. This is a recurring pattern in browser security: stronger storage protections raise the cost of theft, then malware authors search for a path through the browser process itself.

    Browser Sync Expands the Identity Footprint

    The browser profile is valuable even before malware touches it. Browser vendors have spent years making profiles portable across devices. Chrome Sync can save bookmarks, browsing history, open tabs, passwords, payment information, settings, and preferences to a Google account. Edge can sync favorites, passwords, history, extensions, open tabs, autofill entries, and payment information. Firefox Sync can synchronize history, tabs, passwords, payment methods, add-ons, bookmarks, and settings. Each vendor provides protections around that data, yet the product design itself shows how much personal and corporate context now converges in one account-linked profile.

    For an enterprise, that convergence creates a security question that is easy to miss. If a worker uses one browser profile for corporate SaaS, personal webmail, shopping, development portals, AI services, and cloud consoles, those contexts can become tightly adjacent. History can reveal which internal tools are used. Open tabs can show active work. Saved credentials and session material can provide access. Autofill can contain addresses, phone numbers, and payment information. Extensions can sit across all of it. The browser may be one application on the endpoint, but the profile inside it can represent a map of the user’s digital activity.

    Extensions Sit Inside the Trust Boundary

    Extensions make that map more exposed. Chrome’s developer documentation lists extension permissions that can grant access to cookies, browsing history, clipboard contents, geolocation, proxy settings, tabs, web requests, bookmarks, page content, and other browser features. Host permissions can let an extension inject scripts into matching sites, inspect sensitive tab properties, access cookies, or observe network requests. Some permissions are narrow. Others place the extension very close to everything the user does inside a page.

    Mozilla’s permission documentation makes the risk clear. Firefox tells users that an extension with access to data for all websites may read the content of pages they visit and data entered into those pages, including usernames and passwords. This does not mean every extension with broad access is malicious; password managers and content blockers may need deep page access to function. It does mean an extension can occupy a privileged position that deserves the same security review given to other software with access to sensitive business data.

    Research suggests app-store review alone is not enough. A 2025 study of malicious browser extensions reported that researchers were able to develop, publish, and execute malicious extensions through both the Chrome Web Store and Mozilla’s add-on ecosystem under controlled research conditions. A separate 2025 study built a dataset of 7,140 malicious Chrome extensions from earlier years, then examined a newer set of 35,462 extensions and identified 68 malicious extensions that had passed Chrome Web Store vetting. The authors also found that commercial detection systems performed poorly on some known malicious extensions, showing how hard extension classification can be at scale.

    The problem becomes more serious once an extension gains trust and later changes. Extension stores support updates, which is necessary for bug fixes and new features. That same update path creates software supply-chain risk. An extension that was safe when approved can become dangerous after a developer account compromise, ownership transfer, malicious update, or dependency change. Enterprise security teams that review an extension once and then forget it are treating continuously updated code as if it were static.

    Recent research around AI-themed extensions shows how attractive this channel has become. A 2025 preprint examined 5,551 AI-themed Chrome extensions released during a nine-month period and reported 154 previously undetected malicious extensions through a mix of manifest review, domain reputation, runtime network behavior, and human analysis. The researchers described behaviors such as account manipulation, impersonation, traffic redirection, and data exfiltration. The paper had not gone through the same publication path as a peer-reviewed USENIX paper, so its findings deserve that context, but the scale still makes a useful point: popular browser trends create a ready-made disguise for software that asks users for sensitive access.

    Your Browser Can Identify You Without Cookies

    A browser can disclose information even without malware or a malicious extension. Fingerprinting lets a site combine characteristics of a browser and device into an identifier that can remain useful after cookies are cleared. Signals can include screen properties, graphics behavior, fonts, browser features, locale, timing characteristics, and other observable differences. The goal is not always to learn a person’s name directly. It can be enough to recognize that the same unusual browser has returned.

    A 2025 study of real-user browsing found that automated web crawlers substantially undercounted this activity. Researchers followed 30 participants for 10 weeks across interactions involving 3,000 top-ranked websites and reported that automated crawls missed 45 percent of the fingerprinting sites encountered by real users. The gap appeared in part due to logged-in pages, bot detection, and scripts that activated only after certain user actions. That result matters for defenders and privacy researchers: a measurement system that passively loads public pages may fail to see tracking that appears only during normal human use.

    Privacy tools can create their own fingerprinting signals. At USENIX Security 2025, researchers showed that customized ad-blocker filter selections could be inferred through scriptless techniques. Their attacks identified 84 percent of tested filter lists and reduced the median relative anonymity set in their datasets to 48 users, or 0.2 percent of the population, using a small subset of filter rules. The result does not mean ad blockers are bad for privacy. It shows that uniqueness itself can become information. A highly customized browser can reveal a pattern precisely when few other browsers look the same.

    This makes the phrase “browser privacy” broader than cookie settings. Cookies are one tracking mechanism. Browser storage, extension behavior, login state, fingerprinting signals, synced profiles, and permission grants all contribute to what a browser can reveal or retain. Clearing cookies does not erase a device fingerprint. Private-browsing modes limit some local history and storage behavior, but they do not make a user anonymous to websites, network operators, identity providers, or services the user signs into. Chrome and Firefox both state that their private modes do not make users invisible or anonymous online.

    Password Managers Create a High-Value Target

    The password manager inside the browser deserves its own scrutiny. Saving passwords is often safer than reusing simple passwords or storing them in plaintext, and modern browser password managers include meaningful security controls. The risk is concentration. A password store becomes a high-value target once many accounts depend on it.

    USENIX research has repeatedly examined browser-based password managers for generation, storage, autofill, and phishing weaknesses. In 2025, researchers demonstrated phishing attacks that imitated password-manager extension interfaces inside the browser viewport. In a simulation involving 29,800 participants, more than 30 percent of detected third-party password-manager users entered their master password into the imitation, with the rate reaching 58 percent for one manager.

    Mobile browsers add another layer. At USENIX Security 2026, researchers presented AutoFail, a study of Android’s autofill pipeline. They reported critical flaws affecting nine password managers and five widely used mobile browsers. The identified issues could allow attacker-controlled origins to receive credentials, bypass web isolation boundaries, or infer account relationships under the tested conditions. Vendors were notified, and major browser and password-manager developers confirmed the findings and began implementing fixes. The research shows that even a feature built to improve login security can become risky at the boundary where the browser, operating system, webpage, and credential manager exchange context.

    The Browser Is Now Part of Enterprise Identity Security

    For security teams, the answer is not to remove every convenience feature from the browser. The better approach is to treat the browser as a managed security boundary rather than a neutral application. Patch cadence matters greatly. The September 2026 Chrome V8 case shows why delayed browser updates can leave users exposed to flaws with working exploit code. Auto-update policies, version reporting, and alerts for unsupported releases belong in endpoint security operations, not just desktop support.

    Extension governance needs similar treatment. Google provides enterprise policies to block extensions by default, allow approved extensions, block risky permissions, and stop extensions from modifying selected sensitive sites. Microsoft recommends managing Edge extensions by requested permissions and website access, with policy options for allowed extensions, blocked extensions, and runtime host restrictions. Those controls let organizations move away from the assumption that anything in an official store is acceptable for corporate use.

    High-value sites deserve extra isolation from extension access. Identity portals, source-code repositories, payroll systems, administrative consoles, cloud management interfaces, and other sensitive applications have a different risk profile from ordinary browsing. Chrome enterprise controls can prevent extensions from altering selected webpages, including script injection, cookie access, and web-request modification. That gives defenders a direct way to reduce what a compromised extension can see on critical services.

    Session security also needs to move past password theft. Defenders should look for infostealer behavior, browser credential access, suspicious remote-debugging use, anomalous session reuse, impossible travel patterns, and sign-ins that do not match the expected device context. Device-bound session mechanisms such as Google’s DBSC and Microsoft’s token-protection features aim to make stolen authentication material less portable. These controls can shrink the value of a stolen cookie, but they do not remove the need to detect the malware or phishing event that put the browser at risk in the first place.

    Treat the Browser Like a Security Boundary

    Organizations should also decide what browser data belongs in corporate sync profiles. Sync is useful for recovery and multi-device work, but a profile that carries passwords, history, tabs, extensions, payment data, and autofill information across every signed-in device creates a larger identity footprint. Enterprise administrators can control browser policy and sync behavior, and users can limit which data categories are synchronized. The right setting depends on the organization, yet leaving sync entirely to personal preference can produce inconsistent security boundaries between corporate and personal devices.

    Site permissions deserve periodic review too. Camera, microphone, location, notification, clipboard, and file access can accumulate over months of normal browsing. A user may grant a permission for one meeting, one upload, or one troubleshooting session and never revisit it. Security baselines can restrict sensitive permissions to approved origins, and browser vendors expose administrative controls for many of these settings. A permission granted months ago can still matter during a later site compromise or account takeover.

    The central issue is concentration. Browsers became convenient by remembering who users are, where they have been, what they are signed into, what they type, what they allow, and how they prefer the web to behave. Each individual feature solves a real usability problem. Put together, those features make the browser a dense collection of identity and behavioral data.

    That changes how defenders should classify it. A browser is not just another desktop application that happens to access the internet. It is an authentication client, password vault, session store, extension runtime, data-transfer interface, and portal into SaaS. For many users, compromising the browser can expose a clearer path into their work than compromising any single local document.

    So, does your browser know too much? In many environments, yes. The larger problem is that security programs still treat much of that knowledge as ordinary browser state rather than sensitive security data. The browser already sits at the center of identity, cloud access, and daily work. Defensive controls need to reflect the value of what it remembers.

    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 (9/14/2026)

    Netizen: Monday Security Brief (9/14/2026)

    Today’s Topics:

    • The Twitch Extension That Sent 31,000 OAuth Tokens Through Its Proxy Network
    • When the Firewall Manager Becomes the Foothold
    • How can Netizen help?

    The Twitch Extension That Sent 31,000 OAuth Tokens Through Its Proxy Network

    A browser extension promising better Twitch playback quietly created a much larger security problem. Nearly 31,000 Chrome and Firefox users had their live Twitch OAuth session tokens routed through proxy infrastructure controlled by the extension’s operator, placing credentials capable of acting on user accounts inside a network path users had little reason to suspect.

    The extension, Twitch Enhanced Viewer | JeetBot, was published for Google Chrome in June 2025 and Mozilla Firefox in July 2025. Its Chrome listing accounted for roughly 30,000 users, with another 604 installations attributed to Firefox at the time of reporting. The extension advertised improved Twitch playback, including access to 1080p streams in regions where users could face viewing restrictions.

    The security issue was buried inside the way that playback system worked.

    Socket researcher Kush Pandya found that recent versions of the extension redirected Twitch video-playlist requests through proxy servers operated by JeetBot. During that redirect, the extension appended the user’s Twitch OAuth token to the request URL using an auth query parameter. That meant an authentication credential tied directly to the user’s active Twitch session crossed infrastructure operated outside Twitch itself.

    The distinction matters. A Twitch OAuth session token is a bearer credential. Possession of the token can let another party act within the permissions associated with that session without entering the account password or completing a second-factor authentication challenge. Socket reported that exposed tokens could provide access to functions such as Twitch chat, private whispers, account settings, and channel-point activity.

    The implementation created another problem: the token was inserted directly into the URL.

    URLs frequently appear in HTTP request records, reverse-proxy telemetry, debugging systems, application logs, and other infrastructure. In this case, the report found that the OAuth token could be written in cleartext into the operator’s proxy request logs. A mechanism intended to make video playback work had effectively turned a session credential into ordinary request metadata.

    The behavior was also repeated during normal use. Socket reported that current version 85.x builds forwarded the token for channels viewed through the affected playback path. This was not a single authentication event during setup. A user could repeatedly send the same live session credential through operator-controlled infrastructure as they moved between streams.

    Researchers also found evidence that token transmission had changed over the extension’s development. An earlier 4.x version from January 2026 reportedly sent the token through a dedicated set-token endpoint, with backup infrastructure hosted on Deno domains. Later releases moved to the query-string method used by the proxy redirect. The mechanism changed, but the underlying trust decision remained the same: an active Twitch credential was leaving the Twitch authentication boundary and reaching infrastructure controlled by the extension operator.

    JeetBot itself is broader than the extension. Its operator describes the service as a bot platform for Twitch, Kick, and VK Live with features such as text-to-speech, automatic translation, and viewer interaction tools. The service claims more than 26,000 active streamers and one billion processed messages. According to the report, the same commercial service operates the infrastructure through which affected Twitch sessions were routed.
    Part of the initial research also focused on ten Twitch channels whose traffic followed a different path. Socket initially described them as a hardcoded allowlist that did not receive the same token-forwarding treatment. JeetBot developer Aleksandr Popov later explained that the list supported a playback workaround for channels that produced Twitch’s proxy or unblocker error for viewers outside Russia or using VPN connections. Starting with version 85.8.4, users could modify the list themselves through the extension interface.

    That clarification changes the interpretation of the exception, but it does not remove the credential-handling problem.

    Popov disputed describing the extension as malicious and said the tokens were sent to obtain Twitch stream playlists, not to conduct unauthorized activity against users’ accounts. He also pointed to other Twitch playback extensions that send OAuth tokens to remote servers to provide high-quality streams for Russian users. Those extensions, he said, disclose the behavior in their store listings. Popov acknowledged that JeetBot’s prior description and privacy policy did not adequately disclose its own token transmission.

    JeetBot has since changed the implementation. According to its documentation, Firefox version 85.8.7 no longer sends the user’s OAuth token to JeetBot proxy servers. At the time of the report, an equivalent Chrome update had been submitted for store review. Users running an older release were told to disable the extension if an update was unavailable.

    Updating the extension does not solve every part of the incident. JeetBot itself warned that disabling or upgrading the extension does not revoke tokens that were transmitted previously. Once a bearer credential has crossed an unintended trust boundary, stopping future transmission and invalidating the exposed credential are separate tasks.

    The case also points to a larger browser-security problem. Extensions sit in an unusually trusted position. Depending on their permissions, they can observe pages, modify requests, interact with authenticated applications, read browser data, and redirect traffic. Users often evaluate them like small interface add-ons, yet their execution context can place them directly beside credentials, session state, and privileged web traffic.

    For security teams, that makes extensions part of identity security, not merely browser configuration. An extension does not need to steal a password to expose an account. If it can access a live session token, API key, authentication cookie, or another bearer credential, it may reach the same result through a different path.

    The JeetBot incident is a useful example of how that risk can emerge without a traditional exploit. There was no browser memory-corruption vulnerability, phishing page, or credential-stealing executable required. The exposure came from application design: retrieve a sensitive token, attach it to a network request, and send the request through infrastructure outside the authentication provider.

    That type of failure can be harder for users to recognize. The extension still performs the feature they installed it for. Streams load. The browser shows no obvious compromise. Two-factor authentication remains enabled. Nothing necessarily looks abnormal from the user’s perspective.

    Yet the credential protecting the session has already left the environment where the user expected it to remain.

    For the roughly 31,000 users affected by the previous JeetBot implementation, that is the central issue. The incident was not simply about a Twitch playback extension sending unusual telemetry. It was about a browser component placing live bearer credentials into an external proxy path, demonstrating how quickly convenience features can become identity-security risks when session tokens are treated like ordinary application data.

    When the Firewall Manager Becomes the Foothold

    Cisco Secure Firewall Management Center is supposed to give defenders centralized control over firewall policy, managed devices, and network security operations. Recent intrusions show what happens when that same management layer falls under attacker control. Two Cisco FMC vulnerabilities have now been tied to three separate intrusion clusters involving credential theft, state-linked malware, internal network reconnaissance, and Qilin ransomware.

    The attacks center on CVE-2026-20079 and CVE-2026-20316. CVE-2026-20079 is the more severe flaw, carrying a CVSS score of 10.0. It affects the FMC web interface and can let an unauthenticated remote attacker bypass authentication, execute scripts and commands, and gain root access to the underlying operating system. Cisco says the flaw stems from an improper system process created during boot. An attacker can trigger it through crafted HTTP requests. Cisco published the vulnerability in March 2026 and updated its advisory on September 9 after confirming active exploitation.

    CVE-2026-20316 looks less severe on paper. Its CVSS score is 5.3, but its operational value is much greater than that number suggests. The flaw exposes static credentials for a low-privilege FMC account, allowing a remote unauthenticated attacker to log in and access sensitive information. Cisco rated the issue High rather than Medium since the account can be combined with other FMC weaknesses to gain greater privileges. Cisco confirmed exploitation of the flaw in July 2026, the same month the vulnerability was disclosed.

    Cisco Talos has now connected exploitation of these flaws with three different post-compromise activity clusters. The cases show several attacker objectives converging on the same device class. One group used FMC access to extract authentication data. Another deployed tooling associated with a state-linked malware family. A third turned the compromised management server into an entry point for a Qilin ransomware operation.

    The first cluster, tracked as UAT-12197, exploited CVE-2026-20079 and placed a JSP web shell inside the FMC Tomcat webroot. From there, the attackers deployed a malicious Java Archive named cmd.jar. The JAR operated as a command executor and was used to query FMC’s internal database through Cisco’s own OmniQuery.pl utility. One observed query requested user names and authentication data directly from the device’s database.

    This part of the intrusion makes FMC a particularly valuable target. A compromised firewall-management system does not sit at the edge as an isolated appliance. It contains information that can help an intruder learn how the environment is organized, which systems are managed, and which credentials or configuration data may provide the next path inward. UAT-12197 appears to have recognized that value quickly, moving from code execution to credential collection rather than treating the FMC instance as an endpoint to compromise and abandon.

    The second cluster, UAT-11823, went further. Talos assesses with high confidence that this is an advanced persistent threat actor whose tooling overlaps with the Sandworm group. The attackers gained access through CVE-2026-20079 or static credentials and modified a temporary license package to establish a Netcat reverse shell. The malicious package was then processed through FMC’s legitimate package_info.pl utility, which executes during the normal package-installation process with root privileges.

    That technique gave the attackers a useful way to turn access to a lower-privilege account into operating-system-level execution. Rather than importing an entirely separate exploitation framework, the operation abused functionality already present on the FMC server. That same pattern becomes relevant again in the ransomware intrusion.

    UAT-11823 also deployed shell scripts to collect configurations from devices managed by FMC. The configuration data was staged into archives for exfiltration, giving the attackers intelligence on systems sitting behind the compromised management plane.

    The group then installed a variant of Cyclops Blink, a modular ELF implant previously attributed by U.S. and U.K. authorities to Sandworm. Talos found capabilities for persistence, DNS-over-HTTPS resolution, file transfer, credential collection, arbitrary command execution, network scanning, and packet sniffing. Talos stops short of declaring UAT-11823 identical to Sandworm, describing the activity instead as having strong overlap in tooling. That distinction matters when assigning an intrusion to a named state-sponsored group.

    The third cluster shows how similar FMC access can support a very different objective.

    Cisco tracks the operation as UAT-11988 and assesses with high confidence that the actor is a ransomware operator. In this case, the attacker gained access through the static credentials exposed by CVE-2026-20316, then abused legitimate FMC functionality to move from access to full internal reconnaissance.

    The attacker again used package_info.pl, feeding it a malicious license.tmp package containing commands that ran with root privileges. From the FMC system, the operator collected host names, IP addresses, directory information, Active Directory service-account credentials, MySQL credentials, domain account data, computer-object lists, and mappings for sensitive infrastructure. The discovery activity identified systems including domain controllers, Active Directory Federation Services servers, Exchange servers, file servers, and database systems. Collected data was staged in files accessible through FMC and retrieved using HTTP GET requests.

    At that point, the firewall manager had become an internal reconnaissance platform.

    The attackers deployed a Python SOCKS5 proxy and established a reverse SSH tunnel from FMC back to infrastructure they controlled. Talos observed forwarding for services associated with LDAP, LDAPS, Kerberos, SMB, NetBIOS, and Windows Remote Management. That tunnel gave the operator a route from the compromised management device into authentication, file-sharing, and administrative services elsewhere in the victim environment.

    The operation then shifted toward ransomware preparation. The attacker probed endpoints, used tools including Impacket and Invoke-TheHash, deployed custom antivirus killers, and assembled a target list of hosts selected for encryption. Qilin ransomware was then deployed to selected endpoints. Talos said the observed tactics matched those used by Qilin affiliates.

    That sequence is what makes the campaign more significant than another case of an exposed edge appliance being exploited.

    The attacker did not simply compromise FMC and use it as a disposable relay. The system became a bridge between external access and the internal environment. It supplied visibility into managed infrastructure, exposed credentials, provided root-level execution paths, supported traffic tunneling, and helped the operator determine where ransomware would have the greatest effect.

    It also shows why vulnerability severity cannot be read from a CVSS score alone. CVE-2026-20316 carries a 5.3 score and initially provides a low-privilege account. In isolation, that can appear far less urgent than a remote root-level vulnerability such as CVE-2026-20079. The Qilin intrusion demonstrates how deployment context changes the risk calculation. A low-privilege account on a security-management platform can become the first link in a chain that ends with credential theft and ransomware across unrelated endpoints.

    Cisco’s own rating reflects that concern. The company assigned CVE-2026-20316 a High severity rating and warned that the flaw can be chained with other FMC weaknesses for privilege escalation. The company also states that there are no workarounds for either vulnerability.

    Cisco has released hotfixes for affected FMC 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0 branches. The company has advised customers to install the fixes rather than wait for its broader FMC hardening release, which Cisco announced for the week of September 16, 2026. The company also notes that keeping the FMC management interface away from direct public internet exposure reduces the available attack surface, though it does not replace patching.

    Patching also does not clean an already compromised device. Cisco warns that its hotfixes prevent future exploitation but may not resolve an intrusion that has already occurred. For CVE-2026-20316, administrators can search FMC logs for package_info activity involving /var/tmp/license.tmp. Cisco advises customers that find signs of exploitation to contact its Technical Assistance Center for recovery guidance.

    Talos has also released network detections and indicators tied to the campaigns. Snort rules 66075 through 66080 cover CVE-2026-20079, rule 66883 addresses CVE-2026-20316, and rules 66960 and 66961 target related malware activity. Published indicators include hashes for the UAT-12197 web shell and command executor, infrastructure associated with the UAT-11823 reverse shell and Cyclops Blink activity, and an IP address tied to the UAT-11988 intrusion.

    Federal vulnerability guidance has followed the active exploitation. CISA added CVE-2026-20079 to its Known Exploited Vulnerabilities catalog on September 9 after evidence of real-world attacks emerged. CVE-2026-20316 had already entered the catalog on July 29, the day Cisco publicly disclosed the static-credential issue.

    The larger lesson is about where security infrastructure sits in an attack path. Systems such as FMC occupy an unusual position: they are defensive products, but they also hold centralized knowledge about the networks they protect. An attacker who compromises that control point may gain far more than another Linux server. They can gain a map of the environment, access to security configurations, credentials associated with managed infrastructure, and a trusted system from which to reach deeper into the network.

    The three clusters documented by Talos show three versions of that outcome. One used FMC to steal credentials. One used it to support an intrusion involving Cyclops Blink. One used the same class of system to prepare an enterprise for Qilin ransomware.

    The firewall manager was supposed to help defenders control the network. In these intrusions, control of the firewall manager helped attackers learn which parts of the network to attack next.

    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.

  • More Bugs, More Noise, More Pressure

    More Bugs, More Noise, More Pressure

    Vulnerability management has a math problem. In 2024, the CVE Program published 40,077 vulnerability records. In 2025, that figure climbed to 48,244. By the end of the second quarter of 2026, another 35,872 records had already been published, with Q2 alone accounting for 20,709 CVEs compared with 15,163 during Q1. Those figures describe a disclosure system producing security information at a pace few organizations can match with remediation.

    That growth does not mean software suddenly became proportionally less secure. The vulnerability-disclosure system itself has grown. The CVE Program reported more than 500 participating CVE Numbering Authorities in March 2026, up from only 23 CNAs when its federated publication strategy began in 2016. VeMore Bugs, More Noise, More Pressure

    Vulnerability management has a math problem. In 2024, the CVE Program published 40,077 vulnerability records. In 2025, that figure climbed to 48,244. By the end of the second quarter of 2026, another 35,872 records had already been published, with Q2 alone accounting for 20,709 CVEs compared with 15,163 during Q1. Those figures describe a disclosure system producing security information at a pace few organizations can match with remediation.

    That growth does not mean software suddenly became proportionally less secure. The vulnerability-disclosure system itself has grown. The CVE Program reported more than 500 participating CVE Numbering Authorities in March 2026, up from only 23 CNAs when its federated publication strategy began in 2016. Vendors, researchers, open-source projects, CERT organizations, bug-bounty providers, and other groups now publish vulnerabilities across a much broader portion of the technology stack. Better visibility is part of the reason more CVEs appear every year.

    For defenders, the operational effect is still the same. More vulnerabilities enter scanners. More findings appear on dashboards. More remediation tickets compete for engineering time. More patches require testing, deployment, validation, and change approval. A single CVE can appear across hundreds or thousands of systems, meaning tens of thousands of global vulnerability records can translate into far more internal findings.

    Security teams have become very good at finding vulnerabilities. The harder problem is deciding which ones deserve attention first.

    The Vulnerability Queue Keeps Growing

    Academic research has documented that problem for years. A 2020 study by Jay Jacobs, Sasha Romanosky, Idris Adjerid, and Wade Baker in the Journal of Cybersecurity examined vulnerability prioritization using more than 75,000 vulnerabilities and exploitation observations collected in part from more than 100,000 corporate networks. The researchers found that simple remediation strategies based on broad vulnerability characteristics produced poor efficiency. A better approach focused effort on vulnerabilities attackers were more likely to exploit.

    That distinction matters since a CVE record is not the same thing as a remediation decision. A scanner can identify a technical weakness, assign it a severity score, and report every affected asset, but it cannot automatically determine how much operational attention each finding deserves. Organizations have limited maintenance windows, testing capacity, engineering staff, and tolerance for production changes. Vulnerability disclosure has no comparable ceiling.

    This mismatch is one reason CVSS has become both useful and frequently misused. CVSS gives defenders a standardized way to describe technical severity. An unauthenticated remote code-execution flaw is plainly different from a low-impact information disclosure. Problems begin when the score is treated as a complete measure of organizational risk.

    FIRST, which maintains CVSS, states in its CVSS v4.0 guidance that the Base Score measures severity rather than risk. The score describes properties of the vulnerability itself. It does not know where the affected system sits inside a network, whether it faces the Internet, what data it stores, whether exploit code exists, or whether attackers are actively using the flaw.

    That distinction often disappears inside vulnerability-management programs. A scanner reports hundreds of Critical findings and thousands of High findings, and teams naturally start at the top of the severity column. Research suggests that this approach can consume remediation capacity without reliably identifying the vulnerabilities attackers will use.

    Severity Is Not the Same as Exploitation

    Luca Allodi and Fabio Massacci examined this issue in a 2014 study published in ACM Transactions on Information and System Security. Their case-control analysis compared CVSS severity with observed exploitation and found that remediation strategies built mainly around high CVSS scores performed little better than random selection in identifying vulnerabilities tied to real attacks. Evidence that exploit code existed was far more useful.

    The 2020 Journal of Cybersecurity study produced a related finding. The researchers observed exploitation in the wild for only 5.5 percent of vulnerabilities in their dataset. The number is not a universal exploitation rate, but it illustrates the gap between vulnerabilities that exist and vulnerabilities that attackers actually use. A large vulnerability backlog can contain thousands of technically valid findings, yet only a fraction may represent near-term attack paths.

    That changes the question defenders need to ask. “What has the highest score?” is often less useful than “What is most likely to be used against us?”

    CISA’s Known Exploited Vulnerabilities Catalog attempts to answer part of that question. KEV does not list every severe vulnerability. It tracks vulnerabilities for which CISA has evidence of active exploitation. Federal Civilian Executive Branch agencies face defined remediation deadlines for entries added to the catalog, and CISA encourages private organizations to use KEV as part of their own vulnerability-management programs.

    The value of KEV comes from evidence. A Critical vulnerability with no observed exploitation can still matter, but a lower-scoring flaw that attackers are already using may deserve action sooner. The existence of exploitation changes the context in a way severity alone cannot capture.

    Age does not solve the prioritization problem either. Vulnerabilities disclosed years earlier can return to operational relevance once attackers begin using them at scale or locate unpatched systems that remain exposed. Old CVEs regularly appear in active attack chains. A vulnerability does not become harmless simply because it disappeared from security headlines.

    KEV has limits. Evidence of exploitation may arrive after attacks begin, and absence from the catalog does not mean a vulnerability is safe. Security teams also need signals that estimate what attackers may use next.

    Predicting What Attackers Will Use

    The Exploit Prediction Scoring System was built for that purpose.

    EPSS estimates the probability that a published CVE will be exploited in the wild during the next 30 days. The model evaluates features tied to the vulnerability, exploit code, offensive tooling, public references, threat intelligence, age, and observed attacker activity. Scores are recalculated daily as new information appears.

    Its academic foundation comes from research by Jacobs, Romanosky, Benjamin Edwards, Michael Roytman, and Idris Adjerid. Their 2021 paper in ACM’s Digital Threats: Research and Practice presented a data-driven model for estimating exploitation probability rather than using technical severity as a stand-in for attacker behavior.

    Research presented at USENIX Security 2022 extended the same idea. Octavian Suciu and colleagues examined more than 103,000 vulnerabilities and developed a metric called Expected Exploitability. Their work treated exploitability as something that changes over time as proof-of-concept code, technical writeups, exploit modules, and other artifacts become available. Their model improved precision from 49 percent to 86 percent compared with existing exploitability metrics in their evaluation.

    That changing threat state matters. On disclosure day, a vulnerability may have little public technical detail. A researcher may release proof-of-concept code two days later. An exploit framework may incorporate it next. Internet scanning can follow. Commodity attackers may begin probing for exposed systems soon after.

    The CVE identifier never changes. The risk around it can change dramatically.

    Static vulnerability queues are poorly suited to that reality. A flaw assigned moderate priority on Monday may deserve emergency remediation by Thursday. EPSS can move as exploitation probability changes. CISA can add the flaw to KEV once exploitation is confirmed. Threat-intelligence reporting can connect it to active campaigns. Internal asset data can reveal that an affected system recently became Internet-accessible.

    A vulnerability program that assigns priority once and leaves the finding in a fixed queue can miss that entire progression.

    More Data Does Not Automatically Mean Better Prioritization

    Modern vulnerability platforms can ingest CVSS scores, EPSS probabilities, KEV status, vendor ratings, exploit availability, threat intelligence, asset ownership, network exposure, business function, compensating controls, patch availability, and support status. Each signal answers a different question.

    CVSS describes technical severity. EPSS estimates near-term exploitation probability. KEV identifies confirmed exploitation. Asset inventories show where the vulnerable software exists. Exposure data shows whether attackers can reach it. Business context helps estimate what successful exploitation could affect.

    None of those signals works well as a complete answer by itself.

    FIRST makes the same point in its EPSS documentation. EPSS does not know whether a vulnerability exists inside a given organization, what system contains it, what defensive controls surround that system, or what damage exploitation could cause. A high EPSS score on an isolated laboratory system may represent less organizational risk than a lower-probability vulnerability on an Internet-facing identity platform.

    The same CVE can carry very different consequences across two assets. One system may sit behind multiple network controls, contain no sensitive information, and have little access to other infrastructure. Another instance of the same flaw may exist on an external gateway handling authentication for thousands of users. The vulnerability record is identical. The remediation priority is not.

    That is where asset context becomes one of the most useful inputs in vulnerability management. Internet exposure matters. System privilege matters. Data sensitivity matters. Placement within an attack path matters. A vulnerability on a domain controller, hypervisor, VPN concentrator, security appliance, privileged management server, or identity platform can deserve more attention than the same flaw on an isolated low-value host.

    Prioritization Needs More Than One Score

    Recent research increasingly treats prioritization as a multi-signal problem. A 2026 IEEE Access study proposed a model combining KEV, EPSS, and CVSS instead of relying on a single metric. The researchers evaluated the method against 28,377 vulnerabilities and reported 85.6 percent coverage of exploited vulnerabilities, with higher remediation efficiency than a CVSS-only strategy in their dataset.

    The value of that research is less about copying one formula and more about changing how the decision is structured. Teams can begin with evidence of active exploitation, examine predicted exploitability, evaluate technical impact, and then place those signals into the context of the affected asset.

    CISA’s Stakeholder-Specific Vulnerability Categorization model follows a similar idea. SSVC uses decision points tied to exploitation and organizational impact rather than assigning every vulnerability one universal priority number. The approach reflects a simple fact: vulnerability management is local. A flaw can be urgent for one organization and relatively low priority for another.

    This also exposes the limits of “patch everything” as an operational strategy. A fully patched environment is an attractive goal, but production infrastructure has constraints. Patches require testing. Legacy software can break. Operational technology may have narrow maintenance windows. Network appliances can require reboots. Some vendors release fixes slowly. Some products reach end of support long before organizations finish replacing them.

    Treating every unresolved CVE as an emergency can create its own problems. Engineering time gets consumed by low-value fixes. Production systems absorb unnecessary change. The findings that pose the most immediate danger compete with routine patching for the same staff and maintenance windows.

    The 2020 exploit-prediction study frames this as a tradeoff between coverage and efficiency. Fixing everything gives broad coverage but consumes enormous resources. Fixing too little preserves resources but leaves meaningful exposure behind. Good prioritization tries to use finite remediation capacity where it reduces the greatest amount of real risk.

    That requires more than sorting a spreadsheet by CVSS.

    The Queue Has to Keep Changing

    It also requires vulnerability management to operate continuously. Priority cannot remain a permanent label assigned during the first scan. New exploit code, new attacker activity, new CISA entries, new threat reporting, and new asset exposure can all change the decision.

    A useful vulnerability program needs a mechanism for pulling old findings back to the front of the queue when their threat state changes. A three-year-old CVE should not remain buried in a backlog if attackers begin exploiting it against a product the organization still operates.

    The larger trend points to vulnerability management becoming an information-filtering discipline. The CVE Program published 28,961 records in 2023, 40,077 in 2024, and 48,244 in 2025. The first half of 2026 produced 35,872 more. Greater disclosure is a positive development. A flaw does not become safer by remaining undocumented.

    The cost of that visibility is noise.

    Better scanners find more issues. More CNAs publish more vulnerabilities. Researchers disclose more flaws. Software inventories become more complete. Cloud environments create more asset data. Threat-intelligence platforms add more context. Every improvement in visibility gives defenders more information to process.

    The strongest vulnerability programs will not be the ones that produce the longest reports. They will be the ones that can reduce thousands of findings into a defensible sequence of actions.

    That means separating severity from exploit likelihood, confirmed exploitation from theoretical risk, exposed systems from isolated ones, and high-value infrastructure from low-impact assets. It also means accepting that remediation capacity is finite and that vulnerability management is partly an allocation problem.

    More bugs will keep appearing. More scanners will keep finding them. More data will keep entering the queue.

    The security problem is no longer finding enough vulnerabilities to fix. It is making sure the right vulnerability reaches the front of the line before an attacker gets there.

    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.