# Bump AspNetCore.OpenApi + JwtBearer to 8.0.25

**Task**: AZ-496_bump_aspnetcore_8025
**Name**: Bump AspNetCore 8.0.21 → 8.0.25
**Description**: Bump both `Microsoft.AspNetCore.OpenApi` (cycle-1 finding D1) and `Microsoft.AspNetCore.Authentication.JwtBearer` (cycle-2 finding D3) from `8.0.21` to the latest `8.0.x` patch (`8.0.25`) in a single coordinated commit. Closes CVE-2026-26130 (SignalR DoS — not reachable in this app, but the runtime patch is the recommended hardening).
**Complexity**: 2 points
**Dependencies**: None
**Component**: WebApi (`SatelliteProvider.Api`) — dependency upgrade only
**Tracker**: AZ-496
**Epic**: none (cycle-3 security hardening)

## Problem

The cycle-1 security audit (`_docs/05_security/dependency_scan.md` finding D1) flagged `Microsoft.AspNetCore.OpenApi 8.0.21` as one patch behind 8.0.25 due to CVE-2026-26130 (SignalR DoS via unbounded buffer). Disposition was "not exploitable in this app — no SignalR use", but the recommended hardening is still to bump the package.

The cycle-2 security audit added finding D3: `Microsoft.AspNetCore.Authentication.JwtBearer 8.0.21` (added by AZ-487) shares the same 8.0.21 patch line. Pinning a second 8.0.21 package raises the cost of not doing the bump — every additional package implicitly hardcodes the runtime expectation.

Cycle-2 security report explicitly recommends bumping **both** packages in a single coordinated commit so the project's ASP.NET Core 8 LTS footprint stays uniform.

Pre-public-network exposure is the trigger for actually executing this hardening (per `_docs/05_security/security_report.md`). Cycle 3 is a good time because no high-risk new code is shipping concurrently, so the bump can be exercised against the full test suite as a standalone change.

## Outcome

- Both `Microsoft.AspNetCore.OpenApi` and `Microsoft.AspNetCore.Authentication.JwtBearer` are pinned to `8.0.25` (or the latest available 8.0.x patch at implementation time, whichever is higher).
- All unit + integration tests pass against the bumped packages.
- Container image build succeeds (Dockerfile is still pinned to a runtime image ≥ 8.0.25 so the deployed binary actually picks up the patched ASP.NET Core runtime).
- `_docs/05_security/dependency_scan.md` D1 + D3 entries are marked Resolved with a reference to this PBI's tracker ID.
- `_docs/05_security/security_report.md` D1/D3 row moves from Open to Resolved.

## Scope

### Included

- Edit `SatelliteProvider.Api/SatelliteProvider.Api.csproj`:
  - `<PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="8.0.21" />` → `Version="8.0.25"`
  - `<PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="8.0.21" />` → `Version="8.0.25"`
- Edit `SatelliteProvider.Tests/SatelliteProvider.Tests.csproj`:
  - `<PackageReference Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="8.0.21" />` → `Version="8.0.25"`
- Verify the runtime image in `SatelliteProvider.Api/Dockerfile` (or wherever the runtime base image is pinned) is at ≥ 8.0.25. Bump if not.
- Run the full test suite (`./scripts/run-tests.sh --full`) — all green required for this PBI to land.
- Update `_docs/05_security/dependency_scan.md`: mark D1 and D3 Resolved with a one-line note pointing at this PBI's tracker ID.
- Update `_docs/05_security/security_report.md` summary table: D1/D3 status Open → Resolved.
- Verify version consistency: any other 8.0.x ASP.NET Core packages (if any) are bumped to the same patch line to keep `coderule.mdc`'s "consistent package versions" rule satisfied.

### Excluded

- Bumping to ASP.NET Core 9.x or 10.x — this is a patch-level bump only.
- Bumping unrelated packages (Dapper, Npgsql, ImageSharp) — separate decisions.
- Updating `Microsoft.NET.Test.Sdk` (finding D2) — that's a test-only Low and a separate PBI if/when it lands. Mention it in the batch report as the next dep-bump candidate.
- Any production code change.

## Acceptance Criteria

**AC-1: Both packages pinned to 8.0.25**
Given the post-PBI `*.csproj` files
When `grep "Microsoft.AspNetCore" SatelliteProvider.Api/SatelliteProvider.Api.csproj SatelliteProvider.Tests/SatelliteProvider.Tests.csproj` is run
Then both `Microsoft.AspNetCore.OpenApi` AND `Microsoft.AspNetCore.Authentication.JwtBearer` resolve to `Version="8.0.25"`.

**AC-2: Runtime image at or above 8.0.25**
Given the post-PBI `SatelliteProvider.Api/Dockerfile`
When the runtime base image is inspected
Then it pins (or transitively resolves to) ≥ 8.0.25.

**AC-3: All tests pass against the bumped packages**
Given the bumped repository
When `./scripts/run-tests.sh --full` is run
Then all unit + integration tests pass with no new failures vs. the pre-bump baseline.

**AC-4: Security findings updated**
Given the post-PBI repository
When `_docs/05_security/dependency_scan.md` is read
Then D1 and D3 status is Resolved with a reference to this PBI's tracker ID, AND the summary table in `_docs/05_security/security_report.md` reflects the same.

**AC-5: Image build succeeds**
Given the bumped repository
When `docker-compose build` is run
Then the API image builds successfully without warnings about package downgrade or framework conflict.

## Non-Functional Requirements

**Compatibility**
- 8.0.21 → 8.0.25 is a patch-level bump within the 8 LTS line; no public API change expected. If any API drift is observed, STOP and document — this would be unusual and worth investigating.
- The bump must not change `TokenValidationParameters` semantics (cycle-2 JWT validation behavior preserved).

**Security**
- The bump's primary security benefit (CVE-2026-26130) is in code paths NOT reachable from this app. The bump is "hygiene" rather than "active CVE closure", but D1's disposition already explained this and the cycle-2 audit reiterated.

## Unit Tests

| AC Ref | What to Test | Required Outcome |
|--------|-------------|-----------------|
| AC-3   | All existing unit tests | Pass unchanged |

## Blackbox Tests

| AC Ref | Initial Data/Conditions | What to Test | Expected Behavior | NFR References |
|--------|------------------------|-------------|-------------------|----------------|
| AC-3   | Bumped repo | `./scripts/run-tests.sh --full` | All green | Compatibility |
| AC-5   | Bumped repo | `docker-compose build` | Successful image build | — |

## Constraints

- This is a coordinated bump: BOTH packages move together. Do not bump only one.
- The chosen target version MUST be the same across `Api.csproj` and `Tests.csproj` for `JwtBearer` (no version-drift between projects).
- If a higher 8.0.x patch is available at implementation time (e.g., 8.0.27), use that and document the choice in the batch report.

## Risks & Mitigation

**Risk 1: Latent API drift between 8.0.21 and 8.0.25**
- *Risk*: A behavioral change in the JWT bearer middleware between patch versions affects existing test fixtures or production behavior.
- *Mitigation*: AC-3 (full test suite green) is the gate. The Microsoft.AspNetCore patch notes between 8.0.21 and 8.0.25 are short and well-scoped (mostly hotfixes); a behavior drift is unlikely but the test suite would catch it.

**Risk 2: Runtime image upgrade required**
- *Risk*: The Dockerfile base image may still be at 8.0.21; bumping only NuGet packages doesn't help if the runtime is stale.
- *Mitigation*: AC-2 covers this explicitly. Bump the Dockerfile base image in the same commit if needed.

**Risk 3: Cascade bumps**
- *Risk*: Bumping these two packages may pull in transitive dependency updates that conflict with `Microsoft.Extensions.*` (currently at 9.0.10).
- *Mitigation*: A `dotnet restore` (run by the user, not the agent — per AGENTS.md) will surface any conflict immediately. If it occurs, document the cascade and decide whether to fold the cascade in or scope-cut.
