Forty copies of a critical CVE, two suspicious IPs, and a release freeze

Scanner severity is a property of the library; risk is a property of your deployment. Rank on four factors, not one:

1. Reachability. Is the service internet-facing, and is the vulnerable entry point actually reachable? Here the flaw needs polymorphic type handling enabled, which payments-api does not do, and the library is only invoked on a fixed internal schema. That is a real mitigating fact - but it is a configuration fact, one deploy away from changing, so it lowers urgency without closing the finding.
2. Evidence of exploitation attempts. Two IPs probing with crafted payloads against an internet-facing service raises it well above an identical CVE on an internal batch job nobody can reach.
3. Blast radius. payments-api handles payment data. A reporting service does not. Same CVE, wildly different consequence.
4. Blast radius of the fix. If the library comes from a shared base image or BOM, one rebuild may clear 30 of the 40 - find that out before arguing about scheduling 40 separate changes.

Resulting order: payments-api first (exposed + targeted + sensitive), then other internet-facing services, then internal services on a scheduled cycle with a documented, owned, time-boxed exception. "Next quarter" with no owner and no expiry is not a decision; it is a deferral that will be re-discovered in an audit.

Treat them as a reason to investigate now, not as proof of compromise.

• Did the requests reach the vulnerable code path? Runtime attack analysis correlates the observed request with the vulnerable method. If the request was rejected at the gateway, or reached the servlet but never the deserialization call because the schema is fixed, there was no exploitation - that is a materially different answer from "we were attacked and it worked".
• Read the responses. Status codes, response sizes, and timings. A crafted payload that produces a 500 with a different stack shape than normal traffic is more interesting than a clean 400.
• Look for post-request behaviour on the process. New outbound connections, unexpected child processes, file writes, or a change in the process's normal service calls. Deserialization exploitation usually shows up as something else happening afterwards, not as a bad response.
• Do not close the finding because the attempts failed. The probes tell you someone is systematically looking. The configuration that makes the flaw unexploitable today is one feature flag away from being exploitable, and you now know the service is on someone's target list.

In parallel, tighten at the gateway - block or challenge the payload pattern and the source IPs - while the patch is scheduled. That buys time without pretending the underlying finding is solved.

Sequence it, and instrument the sequence.

1. Stop the bleeding at the edge. Gateway/virtual-patch rule for the crafted payload pattern, rate-limit or block the two IPs, and if the endpoint is not needed by every client, restrict it. This is hours, not weeks, and it is independent of the library work.
2. Fix at the source of duplication. Determine whether the 40 services inherit the library from a shared base image or BOM. If they do, one rebuild-and-rollout removes most of the findings at once - a far better argument than 40 change requests. Payments-api goes in wave 1 regardless, and if the base image cannot be rebuilt fast enough, patch it manually and let the base image catch up.
3. Roll out in waves ordered by exposure, not alphabetically: internet-facing and data-sensitive first, internal services last, each wave with a rollback path.
4. Keep runtime vulnerability monitoring on through the rollout so you can confirm the finding actually disappears per process - a rebuild that silently keeps the old JAR in a layer is a classic way to declare victory and stay vulnerable.
5. Watch for regressions. A deserialization library upgrade is exactly the class of change that breaks parsing in production. Baseline the service's error rate and response time before each wave and compare afterwards; a clean vulnerability dashboard with a broken checkout is not a win.
6. Time-box the exceptions. Internal services get a named owner and an expiry date, not an indefinite deferral. A documented, dated exception is a defensible security decision; an open-ended deferral is the thing auditors write findings about.