# Patch Analysis — CVE-2026-58377 (JeecgBoot Broken Access Control)

## Status of the Fix

**There is no official patch for CVE-2026-58377 as of 2026-07-05.**

- NVD / cvefeed.io list the CVE status as **Deferred**.
- SecAlerts lists **"No Patch"** for CVE-2026-58377.
- The highest release tag on `github.com/jeecgboot/JeecgBoot` is **`v3.9.2`**
  (commit `7df07a823fd558be857d0208ccae96342539fbc1`), which is the vulnerable version
  itself.
- The default branch (`master`) HEAD is `32a8dfe94f014f7a9d472bce83e08bb8cf9c10c3`.
  The four OpenAPI controller source files were fetched at this commit and `diff`ed
  against the `v3.9.2` checkout: **all four are byte-identical**. No fix has landed on
  `master` either.

Because no patch exists, the "fixed-version" check mandated by the variant workflow
reduces to testing the **latest release / default branch**, which is identical to the
vulnerable code. The variant is therefore confirmed on the **latest available code**.

## What the (Hypothetical / Recommended) Fix Changes

The parent RCA (`bundle/repro/rca_report.md`) describes the recommended fix:

1. Add `@RequiresRoles({"admin"})` to all mutating endpoints in `OpenApiAuthController`
   (`/openapi/auth/add`, `/edit`, `/delete`, `/deleteBatch`).
2. Add `@RequiresRoles({"admin"})` to the mutating endpoints in
   `OpenApiPermissionController` (`/openapi/permission/add`).
3. Verify the SK signature in `OpenApiController.call()` (the `/openapi/call/**` path).

## Assumptions the Fix Relies On

- **Invariant:** *"Every sensitive OpenAPI endpoint carries a Shiro authorization
  annotation, so `AuthorizationAttributeSourceAdvisor` enforces a role check before the
  method body runs."*
- **Authorization mechanism:** Shiro's filter chain maps `/**` → `jwt`, where `JwtFilter`
  performs **authentication only**. Authorization is purely annotation-driven. The fix
  therefore depends on **every** privileged controller being annotated; any unannotated
  privileged controller is implicitly open to every authenticated user.
- **Role model:** Operations are gated on the `admin` role. Low-priv roles (e.g. `test`)
  must be denied.

## Code Paths the Fix Covers (per the parent RCA recommendation)

- `OpenApiAuthController` — `/add`, `/edit`, `/delete`, `/deleteBatch` (would get
  `@RequiresRoles({"admin"})`).
- `OpenApiPermissionController` — `/add` (would get `@RequiresRoles({"admin"})`).
- `OpenApiController.call()` — SK signature verification.

## Code Paths the Fix Does NOT Cover (the gap this variant exposes)

### 1. `OpenApiLogController` (`/openapi/record/*`) — ENTIRELY UNCOVERED

File: `jeecg-boot/jeecg-module-system/jeecg-system-biz/src/main/java/org/jeecg/modules/openapi/controller/OpenApiLogController.java`

This controller is **not mentioned anywhere in the CVE description** and is **not in the
parent RCA's recommended annotations**. It exposes six endpoints, none annotated:

| Method | Path | Annotation | Service call |
|--------|------|-----------|--------------|
| GET | `/openapi/record/list` | none | `service.page(...)` |
| POST | `/openapi/record/add` | none | `service.save(...)` |
| PUT | `/openapi/record/edit` | none | `service.updateById(...)` |
| DELETE | `/openapi/record/delete` | none | `service.removeById(...)` |
| DELETE | `/openapi/record/deleteBatch` | none | `service.removeByIds(...)` |
| GET | `/openapi/record/queryById` | none | `service.getById(...)` |

**Verified at runtime (this variant):** a low-priv user (role `test`) successfully
listed all 27 audit logs, created a forged log attributed to the admin's auth id, and
deleted a log row (DB row count 1→0). This is a **distinct impact class**
(audit-log disclosure / forgery / tampering / destruction) on a controller the CVE and
its recommended fix completely ignore.

### 2. `OpenApiPermissionController` (`/openapi/permission/*`) — CVE-claimed but not actually exercised by the repro

File: `.../openapi/controller/OpenApiPermissionController.java`

The CVE description names this controller, and the parent RCA *recommends* annotating
`/add`, but the parent `reproduction_steps.sh` **never called** these endpoints — it
only tested `OpenApiAuthController`. This variant exercised them and confirmed they are
open: `POST /add` grants permissions on **any** `apiAuthId` (including the admin's) with
no ownership check, and `GET /getOpenApi` returns the OpenAPI definitions for any
`apiAuthId`. Even after the recommended fix annotates `/add`, `GET /getOpenApi` would
remain unannotated unless explicitly added.

### 3. Read endpoints on `OpenApiController` — uncovered

`GET /openapi/list` and `GET /openapi/queryById` carry no `@RequiresRoles`; any
authenticated user can enumerate/read all OpenAPI definitions (including `originUrl`,
`headersJson`, `paramsJson`). The parent RCA only addresses the mutating endpoints
(`/add`, `/edit`, `/delete`, `/deleteBatch`) of this controller.

## Behavior Before vs. After the (Hypothetical) Fix

- **Before:** Any authenticated user (incl. role `test`) can perform full CRUD on
  `/openapi/auth/*`, `/openapi/record/*`, and `/openapi/permission/*`, and read
  `/openapi/list` + `/openapi/queryById`. The negative control `POST /openapi/add`
  (annotated) correctly denies the low-priv user.
- **After (parent RCA's recommended fix only):** `/openapi/auth/*` mutating endpoints
  and `/openapi/permission/add` would be admin-gated. **But** `/openapi/record/*` (all
  six methods), `/openapi/permission/getOpenApi`, and the read endpoints of
  `OpenApiController` would **remain open** to any authenticated user — the gap this
  variant confirms.

## Target Threat Model / Security Policy

A search of the JeecgBoot repository found **no `SECURITY.md`** and no explicit threat
model that scopes these endpoints as out-of-scope or "by design." The OpenAPI management
endpoints are network-reachable, authenticated, admin-management surfaces (the sibling
`OpenApiController` itself annotates mutating endpoints with `@RequiresRoles({"admin"})`,
establishing that admin-only access is the intended posture). The broken-access-control
finding is therefore within the project's own implied security scope.

## Completeness Assessment

The parent RCA's recommended fix is **incomplete**. It would close the
`OpenApiAuthController` gap (the part the repro proved) and `OpenApiPermissionController.add`,
but it would leave:

- `OpenApiLogController` (`/openapi/record/*`) — **entirely** unprotected (primary variant).
- `OpenApiPermissionController.getOpenApi` — unprotected.
- `OpenApiController` read endpoints (`/openapi/list`, `/openapi/queryById`) — unprotected.

A complete fix must annotate **every** privileged OpenAPI endpoint across **all**
OpenAPI controllers and add ownership checks (see `rca_report.md` Recommendations).