CVE-2026-16723: fastjson remote code execution
Critical at CVSS 9.0 against versions 1.2.68 to 1.2.83, exploitable in the default configuration with no unsafe feature enabled, and no patched version recorded as of the 7 August 2026 update.
Ten years of Alibaba's published middleware, reconstructed from Maven Central upload dates, GitHub advisories, pull-request history, in-repository design proposals and one archive notice. The record shows which of a large publisher's components keep being maintained, which quietly stop, and the property that predicts the difference before you take the dependency.
The question is not whether a published component is good. It is who will still be maintaining it in five years, and whether that answer depends on anything its publisher cares about.
Every system delegates part of itself to code a large company wrote, published and gave away. The adoption decision is usually made on merit: benchmarks, stars, whether the interface is pleasant. Five years later the question that actually matters is a different one. Somebody has to ship the fix for the next critical defect, follow the language and framework underneath it, and answer the issue you filed. The published artefact record tells you who that will be, and it tells you years in advance, if you read the right fields.
Alibaba is the clearest case available, because it published most of a service-governance stack in the open over a decade and every artefact carries a date. A JSON serializer from 2012. An RPC framework handed to the Apache Software Foundation. A flow-control library written for a shopping peak that lands on the same calendar day every year. A registry and configuration server. A distributed transaction coordinator whose own README traces it from an internal project in 2014 to a cloud product in 2016 to the Apache Incubator in October 2023. A Kubernetes scheduling layer that pushes resource policy into the container runtime. Read together, by upload date rather than by README, these components have not shared a fate.
Three of them stopped. The fastjson repository went read-only on 29 July 2026, nine years into an unbroken chain of deserialization advisories, the last of which, CVE-2026-16723, critical at CVSS 9.0, still records no patched version. Sentinel, the in-process flow-control library, went from twelve releases in 2019 to one in each of 2023, 2024 and 2025. The specification that was supposed to move its policy out of the process, OpenSergo, has not had a commit since 29 March 2023, and Sentinel's README still points readers to it. Meanwhile Nacos, the registry and configuration server, has shipped releases in every one of the last nine years and in 2026 is being extended into an agent and MCP registry.
The property that separates them is not popularity and it is not quality. It is whether the publisher can run the thing for you. Nacos, the broker and the transaction coordinator are servers, and a server can be sold as a managed service; Alibaba sells exactly that, and the Nacos README points at it in the quick start. A serializer and a flow-control SDK run inside your process, where nobody can operate them on your behalf. That is the asymmetry this guide is about, and the rest of the page is the evidence, the decisions it should change, and the failure modes it produces.
This guide covers components a publisher released for other people to run, read through Alibaba's Java and Kubernetes middleware between 2012 and October 2026. It does not cover Alibaba's internal systems, its databases, its model stack, or the operation of Alibaba Cloud itself. It carries no production telemetry: no request rates, no utilisation, no incident impact. This session's network policy reached GitHub, Maven Central and the Apache archives and was refused by every engineering blog, documentation site, video host and preprint server, so the blog, talk and paper tiers of the evidence wall are empty on purpose. What remains is dated, primary and checkable, and it is enough for the argument this page makes.
What an adopter of this stack ends up running, and the one structural feature that explains which parts survived.
Assemble the published components the way the publisher's own glue library assembles them and you get three layers. Inside the application process: an RPC client, a serializer, a flow-control SDK holding rules in memory, and a transaction resource manager. Outside it, as servers: a registry that is also a configuration store, a transaction coordinator, a message broker. Below both, on the node: a Kubernetes scheduler and an agent that enforces quality-of-service classes per container. Alibaba's Spring Cloud Alibaba README names exactly this set, Sentinel, Nacos, RocketMQ and Seata, plus three cloud-only services, as "a one-stop solution for application development".
The structural feature worth noticing is that every dynamic behaviour in the first layer is a subscription to the second. Sentinel's rules arrive from a datasource, and the datasources people actually use are the registry and configuration server. Dubbo's addresses arrive from the registry. The transaction manager's decisions arrive from the coordinator. The in-process libraries are, functionally, caches with enforcement attached. That is a reasonable design, and it has a consequence nobody wrote down: the server is load-bearing for every library, while no library is load-bearing for the server. When attention became scarce, the direction of that dependency decided what kept being maintained.
The second thing to notice is that the same function keeps migrating outward. Configuration distribution moved from the client polling over HTTP to a server pushing over a persistent connection: Nacos 2.0.0, on 20 March 2021, "add Grpc as the translating to replace HTTP between client and server". Service discovery moved from registering every interface to registering the application instance, which Dubbo's own migration document frames as a pure scale decision. Resource policy moved from a daemon on the node to the container runtime itself: Koordinator's proposal of 8 June 2023 says its two existing modes, standalone and proxy, "have some constraints" and proposes subscribing to pod and container lifecycle events from containerd or CRI-O instead, so that policy can be applied "before pod's status become running".
Each of those moves is a transfer of responsibility from the thing you deploy to the thing somebody operates. That is the mechanism behind the page's argument, stated as the publishers state it: outward migration is sold as performance, scale or convenience, and it also happens to move the code to where a vendor can charge for running it.
Serializer, RPC client, flow-control SDK, transaction resource manager. Upgrades are your deploys, defects are your CVEs, and the end of maintenance is your migration project. Nobody can be paid to operate this layer for you.
Registry, configuration store, coordinator, broker. The publisher can host it, and does: the Nacos quick start calls the hosted route "the easiest and most convenient way to start Nacos". The paid edition is where the governance features live.
Read from: Nacos, RocketMQ, MSE feature list
Scheduler plus a per-node agent that sets limits through the container runtime. Owned by a platform team, and tracked upstream because the interfaces it hooks, CRI and NRI, belong to the runtime rather than to the publisher.
Read from: Koordinator proposals
Four forks where this stack went one way, with the stated reason and the condition that flips the answer for a team deciding today.
| Decision | Chosen | Rejected | Because | Evidence |
|---|---|---|---|---|
| Serializer default for types named in the payload | Deny by default, in the successor library | A maintained whitelist, which 1.x used | Four advisories in nine years, each defeating the previous restriction | fastjson2 README, 2026 |
| Config and discovery transport | Server push over gRPC | Client polling over HTTP | Stated as a protocol replacement with no published figure | Nacos 2.0.0, 2021-03-20 |
| Transaction coordination | A separate coordinator server, now at a foundation | Keeping it an internal product only | Internal project 2014, cloud product 2016, open source 2019, Apache Incubator October 2023 | Seata README, 2026 |
| Broker evolution governance | A public proposal register with status columns | Roadmaps in blog posts | 70 proposals, each marked accepted, active and released or not, including one for the next decade's architecture that is not released | RocketMQ RIP index, 2026 |
| Keeping an in-process library current with its ecosystem | Maintenance branch only | Merging support for the current Servlet API | Three attempts since issue 2998; the 2026 attempt was rebased onto the 1.8 branch, conflicted, and closed unmerged on 16 June 2026 | Sentinel PR 3618, 2026 |
| Where governance features ship | The paid edition | The open library | Grayscale release and service warm-up are named as enterprise Microservices Engine features | Spring Cloud Alibaba README, 2026 |
Four failure classes, read from the advisory record and the artefact timeline, because no incident review from the publisher was reachable.
A word about the evidence before the cards. Alibaba does not publish post-incident reviews on any host this hunt could reach, so none of the entries below carries a duration, a customer count or a detection delay. What is published, dated and specific is the advisory record: severity, affected version range, patched version, and in two cases a statement about exploitation in the wild. Treat the blast radius field as what it says, unpublished, and treat that absence as the finding it is. A library distributed to tens of thousands of applications has no way to tell you how many of them were hit, which is itself an argument for owning the inventory yourself.
@type key names a class; the parser resolves it and calls public methods on the instance, and a field value drives a JNDI lookup to a server the attacker controls. The advisory for CVE-2025-70974 describes exactly this chain and rates it CVSS 10.0.user-agent header. A request with no credentials was rejected; the same request with the user agent set to Nacos-Server was accepted. The advisory's impact line: "This issue may allow any user to carry out any administrative tasks on the Nacos server".The advisory for CVE-2026-16723 records no patched version, and a 1.2.84 artefact exists on Maven Central dated the same day the repository was archived. No artefact this hunt could reach connects the two: there are no release notes, no repository left to hold them, and the advisory was last updated on 7 August 2026 still showing no fix. Whether 1.2.84 addresses that advisory is open. For an adopter the practical reading is worse than either answer: the final state of a 15-year dependency is a jar with no accompanying record.
These are record numbers, counted from artefact listings and advisory fields. None of them is production telemetry, and the difference matters.
| Measure | Value | Component | Context | As of | Source |
|---|---|---|---|---|---|
| Releases per year, in-process flow control | 7, 12, 2, 3, 3, 1, 1, 1, 1 | sentinel-core | 2018 through 2026, final releases only, 2026 partial | 2026-10-11 | Maven Central |
| Releases per year, registry and config server | 9, 12, 7, 6, 7, 7, 9, 9, 10 | nacos-api | Same years, same counting method | 2026-10-11 | Maven Central |
| Releases per year, RPC framework | 7, 3, 14, 17, 24, 9, 7, 1 | org.apache.dubbo:dubbo | 2019 through 2026; the peak is the Dubbo 3 push | 2026-10-11 | Maven Central |
| Releases of the 1.x serializer in its worst year | 47 | com.alibaba:fastjson 1.x | 2020, against 4 in 2015 and 0 in 2023 to 2025 | 2026-10-11 | Maven Central |
| Advisory range that has no patch | 1.2.68 to 1.2.83 | com.alibaba:fastjson | Critical, CVSS 9.0, default configuration, no AutoType needed | 2026-08-07 | CVE-2026-16723 |
| Advisories naming the serializer that are filed against other people's products | 12 of 20 | Downstream applications | Dated 2024-02-29 to 2025-11-25, long after the library's own fixes | 2026-10-11 | Advisory search |
| Open pull requests, and age of the oldest | 168, oldest 2019-07-17 | Sentinel | Oldest was filed by the project's lead maintainer | 2026-10-11 | GitHub |
| Pull requests closed without merging | 493 | Sentinel | Includes a batch of 2018 and 2019 contributions closed in late 2025 | 2026-10-11 | GitHub |
| Days without a commit, governance specification | about 1,290 | OpenSergo specification | Derived: 2023-03-29 to 2026-10-11, still linked from Sentinel's README | 2026-10-11 | GitHub |
| Public proposals, and the share marked released | 70 listed | RocketMQ | Includes RIP-11, the next decade's architecture, accepted and active but not released | 2026-10-11 | RIP index |
| Lifecycle of one component, internal to foundation | 9 years | Seata | TXC 2014, cloud product 2016, open source 2019, Apache Incubator 2023-10 | 2026-10-11 | Seata README |
Release counts measure published artefacts, not value, and a stable library can be healthy on one release a year. They are used here only to compare projects over the same period and against their own history, and they agree with the independent signals in the same repositories: open pull-request age, branch policy, and whether the current framework version is supported. Three figures on this page are vendor claims with no measurement attached: that the flow-control library "covered almost all the core-scenarios in Double-11 (11.11) Shopping Festivals in the past 10 years", that the broker has "trillion-level capacity", and the "+30% Performance" line in the RPC framework's version table. Treat them as statements about intent. The quantities nobody has published, and which you therefore have to measure yourself, are the ones that would decide an adoption: request rates these components actually sustain, the utilisation gain the node layer delivers, and how many applications were affected by any of the advisories above.
Every source behind this page, graded. The blog, talk and paper tiers are empty because this session's network policy refused every host that carries them.
Critical at CVSS 9.0 against versions 1.2.68 to 1.2.83, exploitable in the default configuration with no unsafe feature enabled, and no patched version recorded as of the 7 August 2026 update.
States that the defect stems from an incomplete fix for CVE-2017-18349 and that it was exploited in the wild from 2023 through 2025, three years before this advisory was published.
High at CVSS 8.1, affecting 1.2.25 upward and patched in 1.2.83. The published workaround for anyone who could not upgrade was to turn on an opt-in safe mode.
Critical at CVSS 9.8, up to version 1.2.24, patched in 1.2.31. The description runs through a third-party web framework, which is how most organisations met the library in the first place.
The registry's auth filter skipped its checks for requests claiming to be peer servers, keyed on the user-agent header. Patched in 1.4.1. The recorded exploit prediction score is 83.483%.
Two authentication bypasses on the same day in April 2021, incorrect access control in August 2021, cross-site scripting in March 2022, hardcoded credentials in the client in July 2022, unsafe deserialization in the Spring integration in August 2023.
"This repository was archived by the owner on Jul 29, 2026. It is now read-only." 25,600 stars, 3,983 commits, and an About line recommending the successor library.
First upload 7 February 2012. The 1.x line peaks at 47 releases in 2020, stops at 1.2.83 on 22 May 2022, and resumes once with 1.2.84 on 29 July 2026. The 2.x compatibility artefact still publishes to the same coordinate, most recently on 2 September 2026.
All 24 files of the final 1.x release, jar, sources, javadoc, pom, signatures and digests, carry the same timestamp on the day the repository was archived.
AutoType "Disabled by default (more secure)" against "Enabled with whitelist" in 1.x, no hardcoded whitelist, group identifier changed, and on the compatibility package, "100% compatibility is not guaranteed".
Of 20 advisories matching the serializer's name, 12 are filed against downstream products, dated between February 2024 and November 2025, each described as a deserialization defect in that product rather than in the library.
The 2.x compatibility artefact is released under the archived project's group and artefact identifiers, 23 times in 2022 and five times in 2026, most recently on 2 September 2026, a month after the repository went read-only.
Claims the library "covered almost all the core-scenarios in Double-11 (11.11) Shopping Festivals in the past 10 years", points at the hosted Microservice Engine and an enterprise edition, and refers readers to the OpenSergo specification as the community's direction.
Seven releases in 2018, twelve in 2019, then two, three, three, and one in each of 2023, 2024 and 2025. The only 2.0 artefact is an alpha dated 14 February 2023.
The newest commit removes blank lines, dated 16 October 2025. Before it, one message fix in September 2024. The last substantive cluster is August 2023, adding a zero-trust implementation and an xDS datasource.
168 open. The oldest, adding exception logging to the tracer, was filed by the project's lead maintainer on 17 July 2019 and is still open. The next two date from August 2019 and May 2020.
Including a batch of 2018 and 2019 contributions, among them adapter modules and low-memory metric implementations, closed on 9 October 2025, six years after they were filed.
Adds a module for the Servlet API that current Spring releases require, behind a Java 17 profile. It replaced an earlier attempt that was also closed without merging. The maintainer moved its base to the 1.8 branch because "active development is currently on the 1.8 branch", after which it was unmergeable.
"An open, language-agnostic cloud-native service governance specification that is close to business semantics." 56 commits, 792 stars, no releases, and the contributors and used-by sections empty.
Newest commit 29 March 2023, a typo fix. The substantive drafts, traffic routing, fault tolerance, traffic lane and database governance, all land between June 2022 and January 2023.
Describes the registry and configuration server, and says it "can also be directly activated and used through the microservice engine (MSE) provided by Alibaba Cloud", calling the hosted route the easiest way to start.
"This version add Grpc as the translating to replace HTTP between client and server", with connection load balancing, limits, reconnection and upgrade and downgrade support, and no published throughput figure.
Between six and twelve releases in every year from 2018 to 2026, with no gap. First upload 14 September 2018, latest in the listing 3.2.4 on 27 August 2026.
2026 releases add an AI registry, agent management, "Agentic Resource Discovery", MCP-related workflows, distributed locks and DNS-based discovery, alongside security hardening.
"For old Dubbo 2 users, there are two choices when upgrading to Dubbo 3, and the only consideration for the decision is performance." Dual registration and dual subscription are the default, and future versions may switch to application-level only.
All Dubbo 2 releases are marked end of life. Dubbo 3 carries a gRPC-compatible protocol, REST support, and a "+30% Performance" claim against an earlier 3.2 release.
Seven releases in 2019, three in 2020, then 14, 17 and 24 across the Dubbo 3 push of 2021 to 2023, falling to nine, seven and one in the years after.
The Alibaba middleware team started TXC in 2014; it became the cloud product GTS in 2016; the open-source Fescar was started in 2019 "based on TXC/GTS"; Ant Financial joined and it was renamed; "In October 2023, Seata entered the Apache Incubator".
70 proposals, each with accepted, activity and release status. Tiered storage, gRPC support and the proxy's remoting protocol are released; the HTTP proxy is "waiting for owners"; RIP-11, "Evolution of The Next Decade Architecture", is accepted and active and not released.
"Trillion-level capacity and flexible scalability" and "million-level message accumulation capacity in a single queue", with no measurement, workload or date attached.
Dated 8 June 2023 with named authors and reviewers. Says the two existing modes "have some constraints", proposes a plugin subscribing to runtime lifecycle events, and carries goals, non-goals, risks and alternatives sections.
Dated filenames from April 2022 to June 2026, grouped into scheduling, koordlet, forecasting and api-machinery, with a template file in the repository.
States the goal as improving efficiency and reliability for latency-sensitive and batch workloads together, reducing interference between containers, and increasing pod density. No utilisation figure is published.
Assembles the four components plus three cloud-only services, tracks the current Spring and Java releases, and names grayscale release and service warm-up as features of the paid Microservices Engine edition.
Releases in every year from 2019, eleven in 2024, latest 2025.1.0.0 on 6 February 2026, while the flow-control library it wraps released once in each of the three preceding years.
An agent framework for Java with 11,000 stars, whose starters integrate with the same registry server "to provide A2A and dynamic config features", and whose quick start points at the publisher's hosted model service for an API key.
A dependency-fate audit, built in an evening and then turned into something that runs every week.
Fetch the artefact listing for your ten most load-bearing third-party components, group version directories by upload year, and print the counts. For Java that is a Maven Central directory listing; the package registries for other languages expose the same dates.
Done when: you have one table of releases per year per dependency, and you can name the two that have decelerated. Teaches: the publisher's attention is a measurable quantity.
In your process, a server you operate, a server someone else operates, or the node's runtime. Resist the urge to add categories: the point is the distance from your deployable.
Done when: every row carries a placement and you can say who would ship a fix for it. Teaches: placement, not popularity, predicts maintenance.
For each in-process component, ask whether the publisher sells anything that would be less needed if the library were better. Check the README for an enterprise edition, a hosted option, or a specification it defers to, then check that specification's last commit date.
Done when: each in-process row is marked as neutral, funnel, or substitute for a paid product. Teaches: how to read a README as a statement of commercial intent.
Wrap it behind an interface you own, implement that interface twice, and measure how long a real swap takes end to end, including the tests you discover are coupled to the library's behaviour.
Done when: you have a number in engineer-days for the exit, and a running build on the alternative. Teaches: the exit cost is dominated by behavioural coupling, not by the interface.
Pick the last three advisories against anything you ship and compute two intervals: publication to your deploy, and the earliest evidence of exploitation to your deploy. The second is the one that matters, and it is usually longer than anyone expects.
Done when: both intervals are on a dashboard with a target. Teaches: patch latency is a property of your pipeline, not of the publisher.
Choose a dependency that is healthy, fork it, build from the fork, ship it to a non-critical service, and keep it there for a release cycle. Write down what broke: build provenance, signing, the internal mirror, the dependency that pinned a transitive version.
Done when: a forked build has served production traffic and the runbook exists. Teaches: owning a fork is an operational capability, and it cannot be acquired during an incident.
Three questions on the intake form: where does it run, who could be paid to operate it, and what does its cadence curve look like over five years. Add one rule: anything in-process with no commercial reason to exist needs a named owner on your side at adoption time.
Done when: the gate has refused or qualified at least one proposed dependency. Teaches: the cheapest moment to pay for an exit is before the import.
These are the queries and URL shapes that produced this page, under a network policy that allowed only code hosts and package registries. They work on any publisher.
https://repo1.maven.org/maven2/<group/path>/<artifact>/https://repo1.maven.org/maven2/<path>/<version>/github.com/<org>/<repo>/releases/tag/<version>github.com/<org>/<repo>/commits/main/pulls?q=is%3Apr+is%3Aopen+sort%3Acreated-asc/pulls?q=is%3Apr+is%3Aclosed+is%3Aunmerged+sort%3Acomments-descgithub.com/advisories?query=<package or project>github.com/advisories/GHSA-xxxx-xxxx-xxxx for ranges and patch stategithub.com/<org>/<repo>/security/advisoriesgithub.com/<org>/<repo>/tree/main/docs/proposalsgithub.com/<org>/<repo>/wiki for improvement-proposal registersraw.githubusercontent.com/<org>/<docs repo>/<branch>/<path>.md