Connected Vehicle Pentest: Telematics, EV Charging (OCPP) and Fleet APIs

A car is now three backends

Pop the hood on a modern connected-vehicle platform and you don’t find one system. You find three, wired to a machine that moves people at speed.

There’s the telematics cloud — the vehicle talks to it constantly, and it talks back with commands: locate, lock, unlock, start, immobilize. There’s the EV charging network, speaking OCPP between charge points and a central system. And there are the fleet companion APIs that let an app, or a fleet manager, reach thousands of vehicles at once.

Each is a real backend with real power over a physical object. A connected vehicle pentest that tests one and waves at the rest isn’t testing the car. It’s testing a corner of it.

And the corner most tests pick is the web app, because it’s the comfortable one. Meanwhile the command channel and the charging protocol — the parts with a physical output — sit untouched, precisely because they don’t look like a normal web target.

Here’s the uncomfortable framing. In a normal app, the worst case is stolen data. Here, the worst case has a steering wheel. That changes what “critical” means, and it changes how the whole thing has to be tested.

Why a connected vehicle pentest is different

Three things make this domain unlike a standard web engagement, and each is a reason a generic scanner falls short.

First, the consequences are physical. A broken authorization check isn’t an information leak — it’s a remote unlock, a tracked location, or an immobilized vehicle in traffic. Safety and security stop being separate words.

Regulators noticed. Frameworks like UNECE R155 now treat vehicle cybersecurity as a type-approval requirement, which means a connected vehicle pentest isn’t only good hygiene — increasingly it’s a gate you have to clear to ship.

Second, the protocols are weird. EV charging runs on OCPP, often over a WebSocket that historical versions left effectively unauthenticated. A tool that only speaks HTTP never sees the charge-point conversation where the real abuse happens.

Third, the blast radius is a fleet. A single flaw in a fleet API isn’t one car. It’s every car on the platform — an unlock-all, a locate-all, an immobilize-all. Scale is the product here, and it’s also the vulnerability.

So a serious connected vehicle pentest isn’t a web scan with a car theme. It’s a test built for command paths, odd protocols, and fleet-wide impact — the things that make this scope dangerous.

3 attack surfaces most tests skip

These three surfaces sit inside one platform, and almost no single test covers all of them. Each deserves its own attention, and the seams between them deserve more.

Because the danger rarely sits neatly inside one surface. It lives where the telematics API hands a command to the vehicle, or where a charging session crosses from the app into OCPP — the joins a single-surface test never looks at.

1. The telematics cloud

The vehicle authenticates to a cloud and accepts commands from it. If that authentication is weak, or the command API trusts a VIN without checking who’s asking, an attacker reaches the car remotely. Locate it. Unlock it. On some platforms, start it. This is the surface behind almost every connected-car headline, and it’s rarely tested as a command channel — only as an API.

The subtlety is that the API often looks fine. It authenticates. It returns clean JSON. What it forgets is the second question — not “are you logged in?” but “is this your car?” Miss that on a command endpoint and every vehicle on the platform is one identifier away.

2. The EV charging network (OCPP)

Charge points and the central system (CSMS) talk OCPP. Older, common deployments run it over an unauthenticated WebSocket, identifying a charger by a guessable ID in the URL. That lets an attacker impersonate a charge point, hijack a session, or read and write messages that start charging, stop it, or bill the wrong account. A web scanner doesn’t speak OCPP, so it walks right past all of it.

And OCPP isn’t a niche corner. It’s the language nearly every public charger speaks to its operator. Get the identity and session handling wrong — as many early deployments did — and the charging network becomes a set of remote-controlled devices sitting on public streets.

3. The fleet companion APIs

Fleet apps and integrations reach many vehicles through one API. Broken object-level authorization here is catastrophic by default: swap an identifier and you’re looking at — or commanding — someone else’s vehicles. The same bug that’s a medium in a to-do app is a fleet-wide incident when the objects are cars.

Scale flips the math. In a normal app, one exposed record is one problem. On a fleet API, one exposed pattern is the whole fleet — so we treat every fleet-scoped authorization check as a potential mass event, not a single-user bug.

Anatomy of a remote unlock — from cloud to car

Follow one command and the physical stakes snap into focus.

1. An attacker signs into the telematics API with an ordinary account.
2. They send an “unlock” command — but swap the vehicle ID for one that isn’t theirs.
3. The API checks that they’re logged in. It forgets to check that the car is theirs.
4. The cloud relays the command to the target vehicle.
5. A stranger’s door unlocks in a parking lot, and the logs show a perfectly normal request.

Five steps, one missing check, one very physical result. This is the shape of nearly every connected-car incident: not an exotic exploit, but an authorization gap on a channel that happens to move a two-ton object.

A connected vehicle pentest walks that path end to end — from the API call to the car door — instead of stopping at “the endpoint returned 200.” The bug is boring. The consequence is a headline.

Multiply that by a fleet and the anatomy gets worse: the same missing check, iterated across every vehicle ID, is a mass unlock instead of a single one. The gap doesn’t scale linearly — it scales to the size of the platform, which is exactly what a connected vehicle pentest is built to measure.

Findings from our engagements: what a connected vehicle pentest surfaces

The specifics are where this gets real. These are real findings from our connected-vehicle engagements, anonymized — the vulnerability classes we keep finding, with every client, vehicle, VIN and log detail stripped out. Each comes with the fix; severities are the ratings these carry in practice.

Remote command via telematics IDOR Critical

A command endpoint accepts a VIN or vehicle ID and acts on it without confirming the caller owns that vehicle. Increment the identifier and you’re locating, unlocking, or immobilizing a stranger’s car. It looks like a plain IDOR; it behaves like grand theft auto.

✓ The fix: enforce per-request ownership checks that bind the authenticated user to the target vehicle, server-side, on every command — never trust a VIN as authorization.

OCPP charge-point spoofing and session hijack Critical

An OCPP endpoint that authenticates a charger only by an ID in the WebSocket URL will happily accept an attacker claiming that ID. From there they hijack a live session, spoof meter values, or start and stop charging on someone else’s authorization. The protocol did what it was told; nobody told it to check who was calling.

✓ The fix: require per-charger TLS client certificates or secure OCPP security profiles, bind sessions to the authenticated identity, and reject messages whose charger ID doesn’t match the credential.

CSMS auth bypass → fleet-wide charge control Critical

The central system is the brain of a charging network. A broken authorization path into its management API hands an attacker every charge point at once — remote stop, remote firmware, mass denial of service. At scale, coordinated switching of many chargers even nudges grid demand. One bug, thousands of stations.

✓ The fix: segment and strongly authenticate every management path, apply least-privilege roles per operator, and rate-limit and monitor bulk operations that touch many chargers.

Fleet API broken object-level authorization Critical

A fleet endpoint returns or commands vehicles by ID without scoping to the caller’s fleet. Change the fleet or vehicle identifier and another operator’s entire fleet is in reach — telemetry, locations, and commands. This is the most common serious API bug there is, made worse by the fact that the objects drive.

✓ The fix: enforce tenant/fleet scoping on every object access, server-side, and test it with two accounts — the only reliable way to catch broken object-level authorization.

Charging session and billing manipulation High

If session ownership or meter values can be tampered mid-flow, an attacker charges their car on your account, or reports less energy than they drew. Not physical, but it quietly bleeds a charging operator and erodes trust in the network.

✓ The fix: treat meter values as untrusted input, reconcile them server-side, bind each session to an authenticated user, and sign or verify the values the charger reports.

Why no single other product does this

Here’s the honest market gap, and it’s the reason a full connected vehicle pentest is hard to buy in one place.

Application security vendors test the web and the APIs and stop — they don’t speak OCPP, and they don’t reason about a command as a physical action. Automotive testing houses go deep on the vehicle and its embedded systems, and treat the cloud, the charging network, and the fleet API as somebody else’s scope. So you get two engagements that never meet, and the command path from cloud to car — the part that actually unlocks a door — belongs to neither.

You can feel the gap in the reports. One says the web app is clean. The other says the vehicle’s firmware is sound. Neither tried to unlock a car through the cloud, because that path sat on the edge of both scopes and the center of neither.

That gap is not academic. The dangerous bugs live exactly at the joins: the telematics API that reaches the vehicle, the OCPP session that trusts an ID, the fleet endpoint that forgets which fleet you are. Testing telematics, charging and fleet separately, and hoping the seams are fine, is how a connected fleet gets unlocked all at once.

Covering all three surfaces in one engagement — web, API, OCPP, and the command paths between them — needs a tester fluent in each at the same time, running at a scale no human squad sustains. That is where an AI-driven approach pulls ahead.

None of this replaces an automotive engineer’s judgment. It gives a connected vehicle pentest the breadth to hold telematics, charging and fleet in one head at once — so the bug that starts in the cloud and ends at the car door doesn’t fall through the gap between two vendors.

How SelfHack AI runs a connected vehicle pentest

SelfHack AI runs specialized agents across the telematics cloud, the charging network and the fleet APIs under one engagement, sharing findings so a weakness on one surface becomes a lead on the next.

• Command-path aware — the telematics API is tested as what it is: a channel that moves a physical car, not just an endpoint that returns JSON.
• Protocol-fluent — a connected vehicle pentest here speaks OCPP, probing charge-point identity, session integrity and CSMS authorization, not only HTTP.
• Fleet-scale reasoning — object-level authorization is tested for blast radius, because one bug across a fleet is the difference between an incident and a recall.
• Exploit-validated, with fixes — every finding ships with a working reproduction and a concrete remediation, then a retest confirms it closed.

It’s the same platform behind our AI pentest benchmark, our external-surface testing, and our blockchain pentest — here pointed at a target where a bug has a turning radius.

How to scope a connected vehicle pentest

Scoping this well is mostly about refusing to test it in pieces. Here’s the path we walk teams through.

1. List all three backends. Telematics cloud, charging network (with its CSMS), and every fleet or companion API. A connected vehicle pentest that leaves one off the scope leaves the seam between them untested.
2. Flag every command path. Which API calls can reach a vehicle — lock, unlock, locate, start, immobilize? Those are the endpoints where an authorization bug becomes a physical act, so they get the hardest testing.
3. Name the OCPP layer explicitly. Charge-point identity, session integrity, meter-value trust and CSMS authorization. If it isn’t in scope by name, a web-focused test will skip it.
4. Test authorization with two accounts, two fleets. Object-level authorization only shows its teeth when a second identity tries to reach the first one’s vehicles — the single most important check on this target.

Do it this way and the first connected vehicle pentest usually surprises people — not with exotic exploits, but with how many ordinary authorization gaps sit on paths that move a car.

FAQ

What is a connected vehicle pentest?

A connected vehicle pentest is a security test of the backends behind a modern vehicle — the telematics cloud, the EV charging network (OCPP), and the fleet companion APIs — plus the command paths that let those systems reach the car. It tests them the way an attacker would, treating remote commands as physical actions, not just API calls.

Do you test OCPP and EV charging specifically?

Yes. OCPP is a core part of this scope. We probe charge-point authentication, session integrity, meter-value trust, and the CSMS authorization that controls a network of chargers — the protocol layer a standard web scanner can’t see.

Are these findings from a real client?

They’re real, and anonymized. These are the vulnerability classes we genuinely find on connected-vehicle engagements — with every client name, vehicle, VIN and log detail removed. We don’t publish any single client’s report, but the patterns, mechanisms and severities are real.

How is this different from a normal API pentest?

A normal API pentest checks the endpoints. A connected vehicle pentest adds two things an API scanner misses: the OCPP protocol layer, and the physical meaning of a command — where an authorization bug isn’t a data leak, it’s an unlocked or immobilized vehicle at fleet scale.

What about the fleet-wide risk?

It’s the one we weight most heavily. A single broken object-level check on a fleet API can expose or command every vehicle on the platform, so we test authorization for blast radius, not just for a single account.

Does this map to automotive regulations?

The classes we test line up with automotive cybersecurity expectations such as UNECE WP.29 R155 and the OWASP API Security Top 10, so findings translate cleanly into an audit or a type-approval conversation.

The verdict

A connected vehicle makes a quiet promise: only you command your car, and only the network controls its chargers. That promise runs through three backends, and it’s only as strong as the weakest of them.

A connected vehicle pentest that tests one surface and trusts the other two isn’t keeping that promise. The real work is covering telematics, charging and fleet as one system, speaking OCPP where it matters, and treating every command as the physical act it is — because on this target, a bug doesn’t leak a record. It moves a car.

If you take one thing from this: don’t buy a connected vehicle pentest as a web scan with a car sticker on it. Insist on the command paths, the OCPP layer, and fleet-scale authorization — those three are where a connected vehicle actually gets taken.

Building or running connected vehicles, an EV charging network, or a fleet platform? Start a scan — order a connected vehicle pentest from SelfHack AI or contact our team. We’ll test the telematics cloud, the OCPP layer and the fleet APIs — and the command paths between them — in one engagement.

Sources

• OWASP API Security Top 10 — owasp.org
• CISA — ICS advisories for EV charging systems — cisa.gov
• NIST — cybersecurity for the connected vehicle / IoT — nist.gov
• Open Charge Alliance — OCPP security profiles — openchargealliance.org

Scope note: findings here are anonymized from real connected-vehicle engagements — the vulnerability classes we find in practice, with every client, vehicle, VIN, operator and log detail removed by design. No single client’s report is disclosed.