CVE-2026-2106: Yeqifu Warehouse Auth Bypass Vulnerability

CVE-2026-2106 Overview

A vulnerability has been discovered in the yeqifu warehouse application affecting the Notice Management component. The vulnerability exists in the NoticeController.java file, specifically in the addNotice, updateNotice, deleteNotice, and batchDeleteNotice functions. This improper authorization flaw allows attackers to manipulate notice records without proper access controls, potentially compromising the integrity of the warehouse management system.

Critical Impact

Unauthorized users can create, modify, or delete notice records in the warehouse system due to missing authorization checks, potentially disrupting operations and enabling data manipulation attacks.

Affected Products

• yeqifu warehouse (all versions up to commit aaf29962ba407d22d991781de28796ee7b4670e4)

Discovery Timeline

• 2026-02-07 - CVE-2026-2106 published to NVD
• 2026-02-10 - Last updated in NVD database

Technical Details for CVE-2026-2106

Vulnerability Analysis

This vulnerability falls under CWE-266 (Incorrect Privilege Assignment), which occurs when the software does not properly verify user privileges before performing privileged operations. In the context of the yeqifu warehouse application, the Notice Management controller exposes multiple endpoints that handle sensitive operations without implementing adequate authorization checks.

The vulnerable component is located in dataset\repos\warehouse\src\main\java\com\yeqifu\sys\controller\NoticeController.java. The affected functions (addNotice, updateNotice, deleteNotice, and batchDeleteNotice) process requests without validating whether the requesting user has sufficient privileges to perform these operations. This allows any authenticated user—or potentially unauthenticated users depending on the authentication configuration—to manipulate notice records.

The attack can be initiated remotely over the network, requiring low complexity to exploit. An attacker with low-level privileges can leverage this vulnerability to gain unauthorized access to notice management functionality.

Root Cause

The root cause is the absence of proper authorization validation in the Notice Management controller. The application fails to implement role-based access control (RBAC) or similar authorization mechanisms to verify that users have the necessary permissions before executing notice-related operations. This is a common oversight in applications where authentication is implemented but authorization logic is missing or incomplete.

Attack Vector

The attack vector is network-based, allowing remote exploitation. An attacker can craft HTTP requests targeting the vulnerable endpoints to:

1. Create unauthorized notices via the addNotice function
2. Modify existing notices through updateNotice
3. Delete individual notices using deleteNotice
4. Perform bulk deletion operations via batchDeleteNotice

The vulnerability allows attackers to bypass intended access restrictions by directly calling these endpoints without proper privilege verification. The exploit has been publicly disclosed through GitHub Issue #58, increasing the risk of exploitation.

Detection Methods for CVE-2026-2106

Indicators of Compromise

• Unusual notice creation, modification, or deletion activity from low-privileged user accounts
• Bulk notice operations performed by accounts that should not have administrative privileges
• API requests to notice management endpoints from unexpected source IPs or at unusual times
• Audit logs showing notice operations without corresponding legitimate administrative activity

Detection Strategies

• Monitor API access logs for unauthorized calls to /notice/addNotice, /notice/updateNotice, /notice/deleteNotice, and /notice/batchDeleteNotice endpoints
• Implement application-level logging to track which user accounts are accessing notice management functions
• Deploy web application firewall (WAF) rules to alert on suspicious patterns of notice API access
• Review authentication and session management logs for anomalies preceding notice manipulation

Monitoring Recommendations

• Enable detailed audit logging for all notice management operations including user identity and source IP
• Configure alerting for bulk deletion operations that exceed normal operational thresholds
• Implement real-time monitoring of privilege escalation attempts against the warehouse application
• Regularly review access control configurations and user permission assignments

How to Mitigate CVE-2026-2106

Immediate Actions Required

• Restrict network access to the warehouse application to trusted networks only until a patch is available
• Implement additional authentication layers or IP-based restrictions for notice management endpoints
• Review and audit all recent notice operations for signs of unauthorized access
• Consider temporarily disabling notice management functionality if it is not business-critical

Patch Information

The yeqifu warehouse project uses continuous delivery with rolling releases, meaning no specific version numbers are available for tracking patched releases. The project maintainers were notified through GitHub Issue #58 but have not yet responded. Users should monitor the project repository for updates and apply patches as soon as they become available.

For tracking purposes, the vulnerability affects commits up to and including aaf29962ba407d22d991781de28796ee7b4670e4.

Workarounds

• Implement a reverse proxy with authorization rules to filter requests to notice management endpoints
• Add Spring Security annotations (@PreAuthorize, @Secured) to the affected controller methods if modifying the source code is possible
• Deploy network segmentation to limit which users can reach the warehouse application
• Configure web application firewall rules to require additional authentication headers for sensitive operations

# Example: Nginx reverse proxy configuration to restrict notice endpoints
location ~ ^/notice/(addNotice|updateNotice|deleteNotice|batchDeleteNotice) {
    # Restrict to admin IP ranges only
    allow 10.0.0.0/8;
    deny all;
    
    # Additional authentication header requirement
    if ($http_x_admin_token = "") {
        return 403;
    }
    
    proxy_pass http://warehouse_backend;
}