In April 2026 somebody got into a law firm, and not through email or the VPN. They came in through the program that firm uses to record its billable hours. The reason: the key that program uses to sign what it receives was written into the code, the same one for every installation. CrowdStrike reports it in a document published yesterday, and what makes it new is not the flaw: it is that, according to the report, this was "the first observed targeting of legal sector-specific software". The first time anyone has been seen going after a trade's own software. And it carries no CVE: we looked, there is no public record.
The lawyers are incidental. What the report describes is a category, and you have one: the software only your sector uses. The clinic's practice system, the accountancy package, the one that plans the fleet's routes, the one driving the lab, the one printing the co-op's delivery notes. It has been in production for fifteen years, a small company maintains it, nobody has ever placed it inside the scope of an audit, and it usually runs on the server where everything else lives.
What a machine key is, in thirty seconds
Classic Windows web applications keep part of their state in the user's own browser and post it back to the server. So that nobody tampers with that blob in transit, the server signs it with a key — the machineKey — and checks the signature on the way back in. Microsoft puts it plainly in a February 2025 advisory: with the key in hand, an attacker can "craft a malicious ViewState using the stolen keys and send it to the website via a POST request", and then the server decrypts it, checks the signature, accepts it, and "the malicious code is then loaded into the worker process memory and executed".
It is not a password somebody steals: it is the seal your server uses to recognise what comes from its own side. And in the four cases below that key was not hidden inside a binary, it sat in plain text in the web.config the product installs. Every customer has it, and so does anyone who ever pasted their config file into a forum asking for help. That same Microsoft advisory says they identified over 3,000 publicly disclosed keys usable for this kind of attack. Nothing needs guessing: it needs a search.
The same mistake, four products, six years
We built this table by searching "hardcoded machineKey" in the NIST vulnerability database. These are not similar bugs: it is the same one, repeated. The first two are from the same vendor, so that is three different houses and four products.
None of them is from Microsoft, Oracle or SAP. They are products that solve one specific problem for one specific audience, that somebody chose well at the time, and that nobody has looked at since. The Gladinet one landed in CISA's exploited-vulnerabilities catalog five days after publication, with a federal deadline of 29 April 2025; the NIST record says "as exploited in the wild in March 2025", meaning it was used before any advisory existed. The other three are not in that catalog, which does not mean nobody has used them: it means nobody has observed and reported it.
One honest caveat, because the table invites a more comfortable conclusion than the data supports: the mistake is not exclusive to niche software. The same family — deserialization leading to code injection — reached Sitecore Experience Manager and Experience Platform up to 9.0 in 2025, and that is not a trade product: it is CVE-2025-53690, in the exploited catalog on 4 September 2025 with a deadline of the 25th. So the thesis is not "small software is worse built". It is a different one, and it comes next: what changes from one product to another is not the mistake, it is how many people are looking.
Nobody is going to find that bug for you
Of the April case, CrowdStrike says the group "exploited a hardcoded IIS machine key vulnerability in Intapp Time Server", time-recording software used almost exclusively by law firms. We went looking for its CVE before writing this, in the NIST database and in CISA's catalog, and did not find one. We wrote about what happens in that window six days ago, when six Linux kernel bugs came out with no CVE and no patch: the gap where no identifier exists blinds the whole tool chain that counts CVEs. We are not repeating it here.
What is genuinely different about your sector's software is the cause of that window, and it is uncomfortable: nobody is looking. Software everybody uses gets looked at by researchers, bug bounty teams and competitors, because publishing a bug there makes a name. In a program used by a few hundred companies in a single trade, that incentive does not exist. It is not that the bug takes a long time to surface: it is that if nobody attacks you, it never surfaces, and the day somebody does, the first to know is the attacker. That is exactly what just happened in April, and it is why the report calls it the first observed instance.
And meanwhile, the background noise
There is one number in the report you can go and check in your identity console today. At a single firm they recorded "nearly 500 distinct failed login attempts to as many accounts from approximately 300 distinct IP addresses in a 30-day period". Nearly five hundred failed attempts against nearly five hundred different accounts, from around three hundred addresses, in a month. One account, one attempt: it is the pattern designed not to trip any repeated-attempt lockout.
It was part of the password-spraying campaign the report calls ORB28, which affected "more than 340 primarily U.S.-based entities across numerous sectors". In your identity console that is a grey line with the failed-sign-in counter at one. It crosses nobody's threshold, and it does not cross it by design. You only see it by grouping on source address instead of on account, which is a query nobody runs until they have a reason to.
The other door is still the telephone
We note it so you do not leave here thinking this is only about old software. The group the report names as the dominant threat to the sector works by "impersonating IT staff to establish remote access sessions and exfiltrate sensitive data within minutes": they pose as the IT department, open a remote assistance session and pull data out within minutes. And in November 2025, according to the same document, they went as far as hiring somebody to walk physically into a firm posing as an internal IT employee. We have written about that before: who verifies it is really you when you call the service desk is the question almost nobody has answered in a written procedure. And the same reasoning holds for the agent your IT provider installs on every one of your machines.
You are not going to audit your vendor's code
We are not going to tell you to audit your vendor's code, because you will not do it and neither can we: that software is closed and your contract gives you no right to look. Nor are we going to tell you to replace it. The program that has fitted the way your trade works for twenty years does not get swapped out over a news story, and anyone who tells you otherwise has never migrated one of these. And no, this is not a problem you solve by buying another scanning tool: the scanner you have does not see this because there is nothing to see, not because it is bad.
What you can do is duller and it works: treat that software as what it is — a high-trust component maintained by somebody else — and put a fence around it. Ask the vendor in writing, because the one who does not reply has already replied. And watch the behaviour of the server it lives on, which is all that is left when there is no signature to look for: an IIS process launching cmd.exe does not need a CVE to be bad news.
And there is one thing you can check yourself, today, without waiting for anybody. On the server where that application runs, open its web.config and look for a <machineKey> block with the values written right there, in plain text. If it is there, that is the key this whole post is about. The NIST record for the Gladinet case goes as far as offering it as a remedy — "a CentreStack admin can manually delete the machineKey defined in portal\web.config" — but do not do it blind in production: touching that key invalidates live sessions and authentication cookies, and in some applications it is the vendor who has to regenerate it. Looking breaks nothing; changing it does, and that needs a heads-up first.
The email we would send this morning
Four questions, to the vendor, in writing. In writing matters: what gets said on the phone is worth nothing in December, when you have to decide whether to renew the contract.
- 1. "Is the application's signing key generated on my installation, or does it ship in the installer?" If the answer is "I am not sure what you mean", note the date of the conversation. If it is "it comes pre-configured", you have the finding of the month and a specific conversation to have with them.
- 2. "Where do you publish security advisories, and do you request CVEs?" A small vendor can do this very well without a portal: a mailing list and a commitment to tell you is enough. What does not work is "we put it in the release notes", because nobody reads the notes of a release the vendor installs themselves.
- 3. "What does it log, and where?" If the application's logs die on that server's own disk, the answer to "what did the attacker do?" is going to be a shrug. Send them where the rest go; it is not a project, it is one line of configuration.
- 4. "If a serious flaw appears tomorrow, how long until I have a patch, and who calls me?" Do not look for a number in a contract: look for whether a person exists. In niche software, the real time-to-patch depends on there being somebody with a name on the other end, and you find that out by asking beforehand, not during.
And two you do not need to ask, because you answer them by looking. First: which account that service runs as, and what permissions it holds in the domain. That is the one that decides whether a bug in that program means "one server" or "the whole domain", and the historical answer tends to be a domain administrator account somebody set in 2014 because that way it worked first time. Second: whether it really needs to be published on the internet. A lot of these programs were published in 2020 so somebody could work from home and nobody revisited it; if today it is reachable over VPN, the form that accepts the signed blob stops being reachable by anyone at all.
Where this fits into what we do
A flaw with no CVE is not caught by signature: it is caught by behaviour. That is where managed EDR and MDR earns its keep, and not because of the brochure: on the server where your sector application lives there is no list of bad versions to compare against, there is a process that suddenly does something it never did, and somebody on call looking at it at three in the morning. The other half is posture review, and it is mostly dull questions: which account each thing runs as, what is published without needing to be, what it logs and where that goes. We do not settle it with a questionnaire; we settle it by going in and looking at the machine. If it is useful, let's talk: what comes out is one list of applications running with more permissions than they need, and another of vendors with nobody to call.
In short
The same mistake — one signing key shared by every customer — has shown up four times in six years, scoring 9.1 to 9.8, and the April case does not even have a record. The difference between software everybody uses and software only your trade uses is not code quality: it is that in the first case somebody is looking. In the second, the one looking is the one coming in. Opening the web.config takes five minutes, and sending the email, ten.
Sources (verified on 29 October 2026): CrowdStrike, "Inside the CrowdStrike 2026 Legal Threat Landscape Report", 28-10-2026 — the phrase "the first observed targeting of legal sector-specific software", the April 2026 case ("exploited a hardcoded IIS machine key vulnerability in Intapp Time Server"), the nearly 500 failed sign-in attempts against as many accounts from around 300 addresses in 30 days, the "more than 340 primarily U.S.-based entities" in the ORB28 password-spraying campaign, the "impersonating IT staff… within minutes" line and the November 2025 episode in which somebody was hired to physically access a firm posing as an internal IT employee all come from there, quoted verbatim; the report also puts financially motivated activity against the sector at 82% and counts 455 legal entities named on leak sites, a 39% year-over-year increase. Machine key mechanics: Microsoft Security Blog, "Code injection attacks using publicly disclosed ASP.NET machine keys", 06-02-2025, with the two quotes about the crafted ViewState and the "over 3,000 publicly disclosed keys". The table of four products comes from queries to the NIST vulnerability database (CVE-2020-13166, 9.8, 19-05-2020, myLittleAdmin 3.8; CVE-2021-39392, 9.8, 15-09-2021, myLittleBackup ≤1.7; CVE-2025-30406, 9.8 in the NIST primary record and 9.0 in the vendor's, 03-04-2025, with the note "as exploited in the wild in March 2025" and the manual remedy "a CentreStack admin can manually delete the machineKey defined in portal\web.config", Gladinet CentreStack ≤16.1.10296.56315; CVE-2026-5426, 9.1 from the publishing CNA and awaiting NIST analysis, 16-04-2026, KnowledgeDeliver prior to 24-02-2026; and, for the caveat that the mistake is not exclusive to niche software, CVE-2025-53690 in Sitecore Experience Manager and Experience Platform up to 9.0, in the exploited catalog on 04-09-2025 with a 25-09-2025 deadline) and from CISA's Known Exploited Vulnerabilities catalog (version 2026.10.28, 1,762 entries, downloaded and read by us: CVE-2025-30406 is listed with a 08-04-2025 date added and a 29-04-2025 deadline; the other three are not listed). The absence of a public CVE for the Intapp Time Server case is the result of our own search in those two sources on 29-10-2026 and may change. The reading about sector software, the CVE-based process and the six questions is ours.
Which account does your sector's program run as?
If the answer takes more than a minute, that is the job. We go through your niche applications one by one: which server they live on, with what permissions, published or not, and what they log. You get a short list of things to fix, and we tell you which ones are not worth touching.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN