CVE-2026-96551: sfturing hosp_order CSRF Vulnerability

CVE-2026-96551 Overview

CVE-2026-96551 is a Cross-Site Request Forgery (CSRF) vulnerability [CWE-352] in the sfturing/hosp_order project, a hospital ordering application hosted on GitHub. The flaw resides in an unspecified function within ssm_pro/src/main/java/cn/sfturing/web/CommonUserController.java and can be triggered remotely by tricking an authenticated user into loading attacker-controlled content. The project does not use versioning, so all commits up to and including 627f426331da8086ce8fff2017d65b1ddef384f8 are affected. The exploit has been publicly disclosed through VulDB and a GitHub issue, and the maintainer has not yet responded.

Critical Impact
An attacker can force an authenticated hosp_order user to submit unintended state-changing requests, resulting in limited integrity impact on user-scoped data.

Affected Products

sfturing/hosp_order repository at commits up to 627f426331da8086ce8fff2017d65b1ddef384f8
ssm_pro/src/main/java/cn/sfturing/web/CommonUserController.java component
All deployments of the project (no versioning is used upstream)

Discovery Timeline

2026-09-23 - CVE-2026-96551 published to NVD
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-96551

Vulnerability Analysis

The vulnerability is a Cross-Site Request Forgery weakness in the CommonUserController class of the Spring MVC (ssm_pro) module. State-changing HTTP endpoints exposed by this controller accept requests without validating a synchronizer token or verifying request origin. When an authenticated user visits an attacker-controlled page while holding a valid session cookie, the browser silently attaches that cookie to the forged request. The server processes the request as if it came from the legitimate user.

Exploitation requires user interaction, typically clicking a crafted link or loading a malicious page. Confidentiality and availability are not impacted, but integrity of user-owned records can be modified within the scope of the victim's privileges. Because the project does not tag releases, defenders cannot rely on a version number to determine exposure.

Root Cause

The root cause is missing CSRF protection on state-changing endpoints in CommonUserController.java. The Spring Security framework provides built-in CSRF token support, but the controller or its security configuration does not enforce it. Authentication is validated through session cookies alone, which browsers attach automatically to cross-origin requests.

Attack Vector

A remote attacker hosts a page containing an auto-submitting HTML form or hidden image tag that targets a vulnerable CommonUserController endpoint. When a logged-in hosp_order user visits the page, their browser issues the request with valid session credentials. The application executes the requested action, such as modifying user profile data or triggering an order-related workflow, without the user's knowledge.

No verified proof-of-concept code is published in a form suitable for inclusion here. Refer to the GitHub Issue #122 and VulDB CVE Details for reporter-provided technical detail.

Detection Methods for CVE-2026-96551

Indicators of Compromise

Unexpected state changes on user accounts (profile updates, order submissions) with no corresponding user-initiated navigation in access logs.
HTTP POST, PUT, or DELETE requests to CommonUserController endpoints carrying a Referer or Origin header from an unrelated third-party domain.
Requests to sensitive endpoints missing an expected CSRF token parameter or header.

Detection Strategies

Deploy a web application firewall (WAF) rule that flags state-changing requests to CommonUserController paths when the Origin or Referer header does not match the application's own domain.
Enable verbose application logging to correlate session identifiers with request origin headers and user-agent strings.
Perform static analysis on the ssm_pro codebase to enumerate all controller methods that mutate state without a CSRF token binding.

Monitoring Recommendations

Track anomalous spikes in requests to CommonUserController endpoints outside typical user activity windows.
Alert on repeated cross-origin submissions from the same client IP against different authenticated sessions.
Retain HTTP access logs including Referer, Origin, and cookie-session mappings for at least 90 days to support forensic review.

How to Mitigate CVE-2026-96551

Immediate Actions Required

Restrict access to the hosp_order application to trusted networks or place it behind an authenticating reverse proxy until a fix is available.
Enable Spring Security CSRF protection in the application's security configuration and require a synchronizer token on all state-changing endpoints in CommonUserController.
Set session cookies with SameSite=Strict (or Lax where compatibility requires it) and the Secure and HttpOnly flags.
Instruct application users to log out of the application when not actively using it, reducing the window for CSRF exploitation.

Patch Information

No vendor patch has been released. The project maintainer was notified through GitHub Issue #122 but has not responded. Because the repository does not use versioning, defenders should apply mitigations directly to their deployed copy and track upstream commits after 627f426331da8086ce8fff2017d65b1ddef384f8 for a future fix. Additional details are available in the VulDB Vulnerability #408953 record.

Workarounds

Add a servlet filter or Spring Security configuration that rejects requests to CommonUserController endpoints when Origin or Referer does not match an allow-list of application hostnames.
Introduce a per-session CSRF token and validate it server-side for every non-idempotent request handled by the controller.
Deploy a reverse proxy rule that strips or rewrites cookies on cross-origin requests to the hosp_order application.

bash

# Example Spring Security configuration enabling CSRF protection
# Add to your WebSecurityConfigurerAdapter or SecurityFilterChain bean
http
    .csrf(csrf -> csrf
        .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
    )
    .headers(headers -> headers
        .contentSecurityPolicy("default-src 'self'")
    );