741 Italian Firms Run Their Invoicing on Software With 17 Advisories and an Unauthenticated Admin Bypass. 93% Are on Consumer Broadband. Nobody Is Coming to Warn Them.

There is a piece of software called OpenSTAManager. It is open source, written in PHP, and it does two things for small Italian companies: it manages technical-assistance jobs, and it issues electronic invoices.

That second part is not optional. Italy mandates electronic invoicing through the Sistema di Interscambio, so a plumbing firm in Bergamo or an electrical contractor outside Bari does not run this because they enjoy accounting software. They run it because the law requires the output, and this is the free way to produce it.

We counted 741 instances exposed to the internet. Then we counted the advisories against it, and the two numbers together describe a problem nobody is going to fix.

Who actually runs it

Of the 741 exposed instances, 731 are in Italy. Five are in Germany, two in Singapore, one each in France, the UK and the United States. This is a national-scale problem in exactly one nation.

The hosting is the part that tells you who these people are. Six hundred and ninety-three of the 741 — 93.5 percent — sit on Telecom Italia Mobile. Not a hosting provider. Consumer and small-business broadband. The rest of the tail is Fastweb, Vodafone Italia, and a scattering of tiny regional ISPs with names like ALBATECK and NOVA NETWORKS. Exactly five instances are on anything resembling professional hosting.

These are not datacentre deployments with an operations team and a maintenance window. These are boxes in back offices, port-forwarded so the owner can check the day's invoices from home. Somebody set the machine up once, probably years ago, and it has worked ever since, which from the owner's point of view is the definition of success.

What is wrong with it

We pulled the full advisory history rather than trusting a headline. Since November 2025 there have been seventeen published advisories: eleven SQL injections, a cross-site scripting flaw, an arbitrary file upload leading to remote code execution, an insecure deserialization leading to remote code execution, and two rated critical.

The two critical ones deserve reading carefully, because of how they fit together.

[CVE-2026-27012](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-27012) is an unauthenticated privilege escalation. An attacker calls modules/utenti/actions.php directly and arbitrarily changes any user's group. You can promote an existing account into Amministratori, or demote anyone you like. No credentials. Version 2.9.8 and earlier.

[CVE-2025-69212](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2025-69212) is an OS command injection in the P7M file-decoding path. Upload a ZIP containing a .p7m file with a malicious filename, and arbitrary commands execute on the server. P7M is the cryptographically signed format Italian electronic invoices travel in. The attack arrives looking exactly like a routine business document.

The chain is the part that matters

Read those two together and something uncomfortable falls out.

CVE-2025-69212 is documented as requiring an authenticated attacker. So is the arbitrary file upload, CVE-2026-38751. On paper, that is a meaningful barrier — an attacker needs valid credentials first.

Except CVE-2026-27012 hands out administrator rights without any credentials at all.

When an unauthenticated bug in a product can grant administrator access, every "authenticated attacker" caveat elsewhere in that same product stops being a mitigation. It becomes a sequencing note. The severity ratings were assigned per-CVE, in isolation, and each one is defensible in isolation — but nobody is attacking a CVE. They are attacking a machine, and the machine has both.

And if chaining seems like too much work, there is a shortcut. [CVE-2026-29782](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-29782): oauth2.php is an unauthenticated endpoint that explicitly sets $skip_permissions = true, loads a database row using an attacker-controlled state parameter, and calls unserialize() on the stored token with no class restriction. One request. No login. Remote code execution. That one is fixed in 2.10.2.

The amplifier nobody planned

There are 32 public repositories carrying exploit code for these CVEs. One, updated today, is fully automated: it authenticates, deploys a PHP web shell through a crafted P7M inside a ZIP, and hands the operator command execution or a reverse shell.

But the thing that genuinely changes the risk is not the exploit code. It is that [CVE-2025-69212](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2025-69212) was built into a HackTheBox machine this season.

That means thousands of people have practised this specific exploit as a graded exercise, with a walkthrough, as part of learning their trade. The capability to attack these 741 boxes has been mass-distributed as education — which is a legitimate and valuable thing for the security industry to do, and also means the skill floor for attacking an Italian plumber's invoicing server is now approximately zero.

This is the supply-side pattern we wrote about earlier today in a completely different context: adversary capability is no longer a function of how valuable the target is. It is a function of what is freely available.

What we actually hold, including a correction

When this first came across our desk we said we had no coverage of it. That was wrong, and we would rather say so than quietly fix it.

Our exploit-harvester has been tracking this since 28 June. It picked up the PoC repositories as they appeared, marked them WEAPONIZED, extracted their target endpoints — /actions.php, /Util/XML.php, config.inc.php, the openstamanager webroot paths — and emitted detection rules automatically. It also captured a hardcoded callback domain embedded in one of the proof-of-concept scripts, flagged honestly as likely attacker infrastructure and marked verify-before-blocking rather than pushed straight to a blocklist.

So the machine knew. The humans had not looked. That is worth publishing about ourselves, because it is the same failure we keep finding in other people's monitoring: the signal was there and nobody read the artifact.

What to do, if this is you

If you run OpenSTAManager: update to 2.10.2 or later, today. That closes the unauthenticated deserialization path. Then check whether your instance needs to face the internet at all — for the overwhelming majority of these 741, the honest answer is that it was exposed for convenience rather than necessity, and a VPN or a simple IP restriction removes almost all of this risk without touching the application.

Then look for the artifacts: unexpected PHP files under your webroot, unfamiliar accounts in the Amministratori group, and any .p7m filename that contains shell metacharacters rather than an invoice number.

If you are an Italian MSP, accountant, or trade association with members who use this — you are the distribution channel that actually exists here. There is no CISA advisory coming. It is not in the KEV catalogue. The people running these machines are not reading English-language security blogs, including this one.

Which is why we are publishing this post again, in Italian, immediately after this one.

Was this useful, or did we miss something? Rate this post below — we read every one, and the low scores are the ones that change what we build.

Every indicator in this post is in the feed. Free.

1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.

Get your free key → analytics.dugganusa.com/stix/register

Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=741-italian-firms-run-their-invoicing-on-software-with-17-advisories-and-an-unauthenticated-admin-by