Or: how a basic user account turned an expensive plant-viewing platform into a “no license found” error page.
Hi, I’m Dan. I’m a security engineer. I’m not great at it, but I’m getting better. I work in the construction industry. Mostly I guess you could call me an observability engineer. I manage the SIEM for the incident guys – make sure logs are logging, analytics aren’t putting out garbage data, that kind of thing. I also work projects like passkey rollout or standing up new email filtering. But SOMETIMES, just SOMETIMES, I get to do the fun stuff – as smelly from vx-underground would put it “poke things with a stick.”
I thought my first post could be about my first CVE. On one of those rare occasions where I got to do the fun stuff, I was tasked with testing some software we were going to introduce to our environment called Universal Plant Viewer (UPV). This is software that presents a CAD drawing through the web browser. It’s meant for engineers and craft workers to view the schematics of a project without needing CAD software – a lot of the folks (welders, steamfitters, electricians, other skilled trade) in the field have iPads or just phones. No one wants to lug around their tools and materials plus a laptop, so they use a browser on their phone instead.
So, I got started testing – I mostly tried things like malformed headers, command injection, LFI, path traversal – the usual. The authentication on it uses a sidecar kind of deal: a bolt-on product called Keycloak. I looked at this thing for a while and it is… pretty solid. The auth methods here are worth a deeper look, so I’ll save that for its own post, but for now just know it uses JWE as opposed to JWT – a quick detour for anyone newer to this than me:
A JWT/JWS (the kind everybody pokes at) is usually signed, not encrypted. The payload is just Base64URL – you can read every claim in it. It gets a header section, a claims section, and a signature section, delimited by a dot .
Format looks like [header].[claims].[signature] – everything is base64Url encoded clear text. A JWE on the other hand, is encrypted. The claims are opaque. You can’t read them. The token also include a some more fields:
- contentEncryptionKey – This is the symetric key used to encrypt the payload. The key itself is encrypted with the recipient’s public key.
- IV or vector – a random value used to randomize the payload.
- Payload/ciphertext – the claims in the token.
I tried a couple of tricks I found from a blackhat presentation in ’23 that goes into greater detail. In the end the authentication was pretty solid, although I’m sure there will be some super cool why-didn’t-I-think-of-that attack against JWE/JWTs in the future.
So when I couldn’t get the authentication, I got myself a valid account and started poking around from the inside. I logged in as a low-privileged user and started messing with stuff – path traversal, LFI, SQLi, deactivating the license, XSS…
“Wait. Why is the site broken all of a sudden? Shit I hope I didn’t corrupt the database” (SQLMap was running after all). I had simply yanked the license. When I hit the endpoint for deactivation, I got a 200 blank response back – I thought it was weird, but no way it really did anything. But it had – I reached out to the project manager to have them take a look and yeah – license had been removed.
That /api/license/deactivateOffline endpoint did exactly what it said it would do – it released the application’s license – but it never came close to making sure I was an admin. That’s it. That’s the whole bug. There’s no clever exploit chain, no memory corruption, no sexy RCE. A privileged action was just sitting there that happily let me take the thing offline. Every other API endpoint had authz checks on them, but for whatever reason this one didn’t.
This is the most common, least glamorous, and consistently top-ranked vulnerability class on the planet: Broken Access Control (OWASP A01:2021). The specific flavor here is a missing function-level authorization check – CWE-862: Missing Authorization.
If it makes you (me) feel better about how mundane this is: I’m far from the first person to come across this. Rhino Security Labs published CVE-2024-55965 for the same thing – a low-privileged “App Viewer” role being able to reach a privileged Restart API and cause a denial of service. Different product, but the same result – a priviledged endpoint that was just there. Waiting.
A “you can turn it off” bug sounds almost cute until you remember where this software lives.
UPV is the digital twin and drawing viewer for industrial plants — the tool a craft worker pulls up on a tablet to confirm which valve, line, or weld is important right now while standing in a power plant or on a bridge. A front-end failure doesn’t affect a single user; it takes the thing offline for everyone on all projects, with no convenient fallback — the product exists specifically so crews don’t have to carry a CAD laptop into the field.
So the impact isn’t data theft or RCE. It’s availability – a simple to execute denial of service that any authenticated user can trigger at will, repeatedly. Imagine reinstalling the license and getting it immediately revoked. It would drive me nuts if I was the support guy. It’s also kind of a funny thing to imagine.
Product: CAXperts Universal Plant Viewer – Setup Portal IIS
Affected versions: < 2026.3.0
Vulnerability class: Broken Access Control – Missing Authorization (CWE-862)
Impact: Denial of Service (loss of availability) for all users
Privileges required: Authenticated, low-privileged (“basic”) user
CVE-2026-36035
CVSSv3: 6.2 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C
Disclosure timeline
2026-02-16: Discovered vulnerability
2026-02-17: Reported to CAXperts, submitted for CVE
2026-02-18: CAXperts confirmed the finding
2026-03-01: TR 15829 Fixed – Improved License handeling (sic)
Anyways, that’s my first one. A missing attribute in the route or function.
More soon – maybe that dive on the JWE stuff, which is interesting in its own way.