Imagine a bouncer who checks IDs from a guest list he printed when the club opened. Anyone already in line at printing time gets scrutinized; anyone who joins the queue afterwards is, as far as the paperwork is concerned, not there, and strolls in. This, in essence, is how HP’s telemetry software decided which code was trustworthy enough to run with the highest privileges in Windows, according to a writeup from a security consultant at the Swiss firm SCRT.
The discovery came during a workstation assessment — the kind of job, the author notes, made plentiful by Windows 10 reaching the end of its life — conducted, as he puts it, back when vulnerability research was not yet fully performed by Claude. The corporate image under review had a thin attack surface and one unfamiliar piece of software: HP One Agent. It appeared to collect telemetry and phone home. More interestingly, it installed a service running as SYSTEM, dropped a collection of plugin DLLs under C:\ProgramData, and periodically executed them with full privileges. Some readers, the author observes, will already be groaning — with good reason.
The design has two halves, and the seam between them is the whole story. The service, hp-one-agent-service.exe, invokes hp-plugin-executor.exe, which enumerates plugin folders under C:\ProgramData\HP\telemetry\collectors, checks every *.dll it finds with WinVerifyTrust, then loads the plugin and calls its LoadPlugin() function. Program Files, where the executables live, is properly locked down. The plugin folders, however, sit in ProgramData, where any authenticated user on the machine can add files. The author says he is sure there is a good reason for this arrangement but notes that, as the attacker in the room, he rather enjoyed it.
Signing a malicious DLL with a legitimate code-signing certificate would have ended the exercise immediately, but that requires a certificate, which the author did not have. Instead he noticed that plugins routinely import helper DLLs that do not exist in their own folder — one telemetry plugin, for example, imports functions from hp-shared-error-v2.dll, which lives in a different collector’s folder. Windows resolves such dependencies by looking in the plugin’s own directory first. And that directory is user-writable. Classic DLL sideloading, blocked by exactly one thing: the executor verifies the signature of every DLL in the folder before it loads anything.
Enter the bouncer and his printout. The verification loop works by calling FindFirstFile(“*.dll”) and then FindNextFile() over and over, checking each returned file. The catch, the author explains, is that these calls cache at least partial results from the moment the enumeration begins. A DLL added to the folder after the first call may never be enumerated, hence never verified — yet can still be found by the loader later, as a dependency. So the exploit strategy is simple to state: wait until verification starts, then drop the malicious DLL while the bouncer is busy checking the people who arrived on time.
Races against a computer are won two ways, the author notes: be impossibly precise, or make the window bigger. He chose the second, stuffing the target folder with multiple large, legitimately signed DLLs so that WinVerifyTrust had plenty of homework — more time for the payload to slip in. To know when the bouncer was mid-check, he planted a trigger DLL, a signed copy of a legitimate one, and repeatedly tried to open it for writing; the moment Windows refused because someone else had the file open, the executor was clearly reading it, and that was the signal to drop the real payload.
Even then, the first attempt did nothing: simply placing a hostile hp-shared-error-v2.dll produced no code execution via DllMain. The working version used DLL proxying — implement the exports the plugin expects, forward each call to the genuine DLL in its real folder, and append a small bonus payload, such as adding a local administrator account. The plugin keeps working normally, nobody notices anything, and the extra code runs as SYSTEM: a textbook local privilege escalation. The author declines to publish his proof of concept, on the grounds that it would burn your eyes, but says reproduction from his description should be straightforward.
Every version of HP One Agent prior to 1.3.214.7339 is affected; that release introduced the fix, which the researcher has not tested. The vulnerability is tracked as CVE-2026-5064, which HP’s bulletin, as reproduced by CVE trackers, describes as potentially allowing escalation of privilege and denial of service; one tracker, Strix, scores it 8.5 out of 10, squarely in high-severity territory. The build on the assessed workstation was 1.1.789.5870, and the researcher verified that the then-newest release, 1.1.912.0346, was identical in the relevant respects — important, because an older privilege escalation in the product had already been reported by someone else and he needed to know he wasn’t rediscovering it.
Then comes the other vulnerability in this story, the organizational one, best told as a sequence of calendar entries. 17 August 2025: initial disclosure to HP through a web form, the instrument whose primary function is to absorb information without confirming a recipient. 24 August: a follow-up email asking whether the web form had been received. 25 August: HP requests the proof of concept; it is sent, again. 29 September: another nudge, asking if anyone could reproduce the issue. 5 December: another nudge, with notice that a blog post was coming; HP replies the same day that a fix exists but its release has been postponed to the first week of January, and the researcher agrees to wait.
26 March 2026: a status inquiry. 27 March: HP reports that the bulletin is still being drafted and a CVE reserved — and, almost in passing, that the patch has been available in the Windows Store since 19 January. The fix, in other words, had been sitting in public for over two months while its existence was treated as embargoed information. 30 March: the researcher asks to publish; HP asks him to hold until the security bulletin appears, expected in a few days. 9 April: HP says the fixes have shipped via Windows Update — and that the commercial version of the product is still vulnerable. 17 July: a status inquiry. 24 July: HP replies that the bulletin was published. In June. The researcher learned of its release the way one learns of most things at HP, it seems: by asking.
From the first web form to the bulletin that arrived unannounced, the disclosure took nearly a year. The technical flaw is the kind that will be fixed and forgotten — enumeration is just a bad way to do security, in software as in nightclubs, because anyone can learn to arrive after the list is printed. The slower bug, the one where reporting a hole in a product takes thirteen months of follow-ups, appears to have no patch scheduled.