Sa-Token CVE-2025-15117

No vendor-released patch has been identified at time of analysis, as the Sa-Token maintainers neither responded to the disclosure nor published a fixed version; the primary action is therefore to stop using the vulnerable code path rather than to wait for an upgrade. The most effective mitigation is to reconfigure Sa-Token to a non-JDK serialization backend (for example a JSON-based serializer) so that SaJdkSerializer is never invoked; the trade-off is that existing persisted sessions or tokens serialized in JDK format may become unreadable and could require a migration or forced re-authentication window. Where the JDK serializer cannot be swapped out, restrict every endpoint that can feed bytes into ObjectInputStream to trusted, authenticated principals, and introduce strict input validation, signature verification, or an ObjectInputFilter that allow-lists expected classes before readObject executes; class allow-listing can break legitimate deserialization of unexpected but valid types and needs testing. Because the assessed impact is availability-only (VA:L) with high attack complexity and PR:L, network segmentation and rate limiting around any exposed session-handling endpoints provide limited additional value compared with serializer replacement. Monitor for denial-of-service style failures or deserialization exceptions as an indicator of attempted abuse, and track the GitHub CVE repository and VulDB entries for a future maintainer fix; if an upgrade is eventually published, apply it as the definitive remediation over any of the above compensating controls.