Adobe's CVE arrived 120 days after our report, Citrix closed a report with no CVE, and NetScaler was exploited before its advisory. What your team can do while a disclosure window is open.
On April 9, Spektion Research reported a vulnerability in Adobe Genuine Service through VulnCheck, our disclosure partner and CNA. Adobe shipped a fix in July without a security advisory. The CVE appeared on August 7, 120 days after our first report. If your vulnerability workflow starts from published CVEs, August 7 was your first prompt to investigate. The vulnerable named pipe had been on endpoints the whole time.
We reported a similar named pipe in Citrix Workspace App for Windows 2503 on April 29. Citrix closed the case, saying it couldn't reproduce the behavior in supported releases, and no CVE or advisory followed. In a separate NetScaler case, exploitation was under way for weeks before the September 27 bulletin.
These cases expose a timing problem for any program that starts with a CVE. Coordinators set disclosure deadlines, and vendors decide most of what happens inside them: the response, the fix, and what customers hear. Your software keeps running through all of it.
A vulnerability disclosure window is the period between a researcher's private report to a vendor and the public disclosure of the issue. In coordinated vulnerability disclosure, the vendor uses that time to investigate and prepare a fix while the researcher or a coordinator prepares the advisory. VulnCheck managed our Adobe disclosure as our CNA partner, including follow-up with Adobe, the CVE request, and its own advisory.
Under most CNA disclosure policies, vendors get 90 to 120 days to fix an issue or publish an advisory. Google Project Zero uses 90 days, and TrendAI Zero Day Initiative uses 120 for its standard process, with limited extensions and shorter windows for some faulty patches.
Our Adobe report ran on VulnCheck's policy, which sets 120 days with no deadline extensions, treats a published patch as public disclosure, and provides for an uncoordinated advisory if the deadline passes without a patch or advisory. It shortens the deadline to seven days when VulnCheck determines the issue is exploited in the wild. VulnCheck reserves discretion to change its process when needed.
The deadline doesn't stop the affected software from running. Inside the window, a patch can ship without an explanation, a vendor can decline a CVE, or an attacker can act before the bulletin. Our Adobe and Citrix reports and the NetScaler case each show one of those outcomes.
Under coordinated disclosure, up to the coordinator's deadline, and Adobe used all of it. We contacted Adobe PSIRT on April 9. Adobe acknowledged the report on April 27 and confirmed the issue in late May. It told VulnCheck on August 5 that the fix had shipped in July. VulnCheck requested a CVE ID on August 6, a day ahead of its deadline, and Adobe published CVE-2026-71381 on August 7.
Adobe Genuine Service created named pipes with an access control list granting EVERYONE_W, and the pipe mode accepted remote clients. AGSService.exe served one of the pipes as SYSTEM. Adobe installs the service by default with Acrobat Reader and Creative Cloud. Skipping it means unchecking a box under "Included with your download" on the Reader download page, so anyone who clicks straight through gets it. Our technical disclosure documents the calls, versions, and conditions in detail.
I spent years on the offensive side looking for gaps like this. A pipe that Everyone can write to, served by a process running as SYSTEM, gives an operator an interaction point with privileged code. When that service rides along with Acrobat Reader and Creative Cloud, the operator builds the method once and reuses it across machines while defenders wait for a name to put into a ticket.
Fixes take engineering and testing. Until August, customers had no public CVE to match against their assets. Even after publication, they had to check the installed Genuine Service version. In our testing for the August disclosure, current installers still bundled a vulnerable 8.x build. You read that correctly. The update task, which runs every six hours, didn't run consistently on standalone Acrobat Reader installs either. An Adobe update announcement didn't prove that a given endpoint was fixed.
A silent patch is a security fix a vendor ships without an advisory, CVE, or release note that identifies the vulnerability it fixes. Adobe's July release was one. Adobe told VulnCheck on August 5 that the July release fixed the issue, and we had to examine the updated service and validate the fixed version ourselves. Adobe eventually published the CVE and VulnCheck issued its own advisory, so the issue did reach the public record. The interval between the fix and those records still mattered.
In July, your change process might approve the Adobe update without a security bulletin or affected-version list. Some endpoints update and others keep running the old service. Your program has no prompt to inspect the pipe or confirm which machines still expose it.
The CVE also arrived with a vendor score well below ours. Adobe scored the issue 4.0 under CVSS 3.1, a medium, with a local attack vector. If your SLA starts the clock only on highs and criticals, it never started for this one. Spektion assessed it at 8.1 under the same version with a network attack vector, based on the pipe mode, and VulnCheck's advisory also rates it 8.1 with a network vector under CVSS 4.0. We observed the pipe and its descriptor on a clean install but didn't attempt a write from a second host. An authenticated SMB session is normally required, and anonymous access depends on null-session settings. Those conditions belong in the remediation decision, and a CVSS lookup won't surface them.
It costs you the facts you need to make a decision. While the vendor works the case, your team still has to decide whether to block reachability, add a detection, replace the software, or accept the exposure. Without an affected-version list, it can't know whether the next build removes the behavior.
Our Citrix report shows how long that can last. On April 29, we sent Citrix a finding in Workspace App for Windows 2503. WFICA32.EXE created an externally reachable, bidirectional named pipe whose ACL granted Everyone write access. In our observation, the application accepted input without authenticating the caller, verifying its identity, or validating its process ID. On an engagement, a bidirectional pipe that takes input from anyone without checking who's calling is the first thing I'd start fuzzing. The Spektion sensor captured the operating system calls, parameters, and metadata while the software ran. As I wrote when the case closed, Citrix PSIRT took more than three months to respond meaningfully.
A fast acknowledgment doesn't change the exposure either. Adobe acknowledged our report in 18 days, and the vulnerable service kept running on customer endpoints until the July fix reached them, if it did.
Yes. Citrix said it could not reproduce the Workspace App behavior in supported releases and closed our report. It issued no CVE, advisory, affected-release list, or account of the change between builds. We haven't checked whether later builds still create the pipe, and Citrix didn't say which build changed the behavior or whether that change was intentional. A customer needs both facts to verify an upgrade.
"Supported" carries a lot of weight in that answer. The software we observed reported version 25.3, the 2503 release line. Citrix's Workspace App lifecycle table lists the line's 2503.2 release reaching end of maintenance on September 29, 2025 and end of life on November 22, 2026. By that table, every 2503 build was past maintenance by April 2026, and 2503.2 was still months from end of life: two states Citrix's own documentation keeps separate. Support policy governs whether a vendor builds you a fix. Disclosure governs whether you learn you're exposed, and Citrix's answer applied the first to the second.
Age alone doesn't bar a public record. CVE Program policy permits assignments for end-of-life products. A vendor CNA that declines must tell the reporter why. The reporter can then escalate to the CNA of Last Resort, which can assign and publish if it deems it appropriate, and that record must carry the "Unsupported When Assigned" tag. Whether our Citrix report qualifies is a separate question, and the version's age doesn't settle it.
Without a public record, a scanner that maps versions to CVE ranges has nothing to match, and an SLA keyed to CVSS has no clock to start. The endpoint keeps running the same code while the dashboard shows no finding.
Yes. Citrix disclosed CVE-2026-88771 and CVE-2026-88772, two of eight NetScaler CVEs in its September 27 bulletin, and the bulletin says exploits against unmitigated deployments had been observed. Mandiant and Google Threat Intelligence Group reported that exploitation of CVE-2026-88772 had been under way since at least early September, and Mandiant's CTO put the count at dozens of organizations across North America and Europe. For those weeks, CVE-2026-88772 was a zero-day, and a CVE-driven queue had nothing to put on it.
Citrix then disclosed CVE-2026-88779 in early October for a separate NetScaler issue, after customers had already applied the September updates, and CISA added it to the Known Exploited Vulnerabilities catalog on October 4. On October 8, Citrix published a third bulletin, CVE-2026-107406, for SAML deployments. Citrix doesn't report it as exploited, but its affected range includes both earlier fixed builds on appliances acting as a SAML identity provider, so those appliances needed a third upgrade in 11 days. If you run an internet-facing appliance, that sequence calls for patching and a compromise investigation. A clean version number after an update can't tell you what happened before it.
NetScaler is an appliance, and Spektion's endpoint sensor didn't detect those vulnerabilities. I'm using the case for its disclosure timing. Appliance teams need their own logs, vendor guidance, and threat intelligence.
VulnCheck's first-half 2026 analysis found evidence of exploitation on or before CVE publication for 23.43% of the known exploited vulnerabilities in its dataset. The figure covers that cohort only. It's enough to show that a program waiting for publication will sometimes start after attackers do, the same trend behind the negative time-to-exploit numbers we covered in May.
Start from the same CVE catalog your scanner uses and add runtime evidence from the software executing on your endpoints. Keep using the catalog, EPSS, exploit intelligence, and vendor bulletins. We built the Spektion Platform as endpoint vulnerability management on that same catalog, then pointed the sensor at the conditions I used to hunt for: who can write to a pipe, which process serves it, and with what privilege. Spektion shows you which CVEs are actually exploitable on each machine, finds the vulnerabilities that never get a CVE, and ships you a control when there is no patch. During a disclosure window, runtime evidence gives your team an undisclosed vulnerability to investigate before a public identifier exists. If you run a CTEM program, that's the exploitability evidence it needs while the CVE feed is still silent.
For Adobe and Citrix, the sensor observed pipe creation, permissions, mode, and process context as the software ran. With that evidence, our researchers could ask which version was running, whether another host could reach the pipe, who could write to it, and whether the server authenticated the caller or validated input. A version string can't answer those questions.
In practice, the finding lands in your vulnerability queue with the affected endpoints, process, version, observed behavior, and supporting evidence. Your analyst and the application owner can examine reachability, caller permissions, authentication, input handling, and server privilege. They can also see whether the software is running and what the software can reach if it is compromised. A remotely reachable pipe alone doesn't prove an exploit path, and these details decide whether one exists.
If there's no patch or advisory, Spektion provides preventive and detective controls for the finding. Your team can use an OS configuration to block the observed path and detection content for that behavior, then work with the application owner on an upgrade or removal plan. The control should name the behavior it addresses. A generic "monitor for exploitation" ticket gives the person configuring it nothing to work with.
When a CVE appears, Spektion can identify which endpoints require action from the running version, privilege, reachability, and observed behavior. Your team can check whether the fix removed the condition and deprioritize the other endpoints with evidence. One customer cut emergency patches by 60%.
The vendor gets time to investigate and ship a fix. Your team still owns the systems running that software in the meantime. Give your queue a way to accept evidence before an identifier exists, and require proof that the behavior changed before anyone closes the finding.
If you're sitting on a vendor finding that's stuck in a disclosure window right now, hit me up. I'd like to hear how you're handling it.
See how the Spektion Platform finds undisclosed vulnerabilities on your endpoints.
Many exploitable vulnerabilities never get a CVE. Book a runtime assessment and Spektion will show what's actually exploitable across your endpoints.