Authentication Bypass in pac4j-jwt JwtAuthenticator via JWE-wrapped PlainJWT

This repository is a self-contained Java lab/PoC for CVE-2026-29000 rather than a general-purpose exploit framework module. The meaningful code is concentrated in `lab/src/main/java/com/demo/`: `App.java` starts a SparkJava web server on port 4567, generates an RSA keypair at startup, exposes demo API routes, and switches between vulnerable and patched JWT validation modes; `VulnerableAuthenticator.java` reproduces the flawed pac4j-jwt JwtAuthenticator behavior; and `PatchedAuthenticator.java` shows the corrected logic. The core exploit capability is an authentication bypass against JWT/JWE validation logic. In the vulnerable authenticator, when a token is an `EncryptedJWT`, the server decrypts it with its RSA private key and calls `payload.toSignedJWT()`. If that conversion returns null, the code does not fail closed; instead it parses the decrypted payload as a `PlainJWT` and directly returns its claims. That means an attacker can supply a JWE containing an unsigned inner JWT with arbitrary claims and have those claims trusted without signature verification. The patched authenticator explicitly rejects decrypted payloads that are not `SignedJWT` objects. Operationally, the lab exposes endpoints to demonstrate the full attack chain: `/api/login` issues a legitimate token, `/api/forge-token` creates a forged attack token for the bypass scenario, `/api/dashboard` is the protected resource that trusts the token claims, `/api/public-key` exposes the server public key as JWK, and `/api/config` toggles vulnerable mode on or off. The dashboard logic treats `administrator` or `admin` roles as privileged and returns `Welcome admin.` when the forged claims are accepted. Repository structure is mostly lab scaffolding. `Dockerfile` and `docker-compose.yml` package and expose the service on 4567. `lab/pom.xml` defines Java 17, Nimbus JOSE+JWT, SparkJava, Gson, and SLF4J dependencies. `run-lab.ps1` bootstraps Maven from `archive.apache.org`, builds the project, launches the backend, and opens the browser to the local lab URL. The bundled `tools/apache-maven-3.9.6/` directory is support tooling and not part of the exploit logic. Overall, this is a realistic educational PoC demonstrating a JWT/JWE signature-bypass condition and its remediation, not malware or a weaponized exploit kit.

Small standalone Python proof-of-concept repository for CVE-2026-29000 with 3 files: one exploit script, a README, and a GPL license. The main file, CVE-2026-29000.py, is the sole code artifact and contains the full exploit workflow. It uses requests to retrieve a JWKS document from a target-supplied endpoint, selects the first RSA key, builds an unsigned JWT with alg=none and attacker-controlled claims, then uses jwcrypto to encrypt that JWT into a compact JWE using RSA-OAEP-256 and configurable content encryption (default A256GCM, optional A128GCM). The exploit does not deliver code execution; its capability is authentication and authorization bypass via forged identity tokens. It is operational rather than framework-based: the operator provides the base URL and JWKS path, and the script outputs a ready-to-use forged token. The README documents likely discovery endpoints (/api/auth/jwks, /.well-known/jwks.json, /.well-known/openid-configuration), hints for locating expected crypto parameters in /static/js/app.js, and notes that the forged token may be used either in an Authorization header or by replacing a browser sessionStorage token. Overall, the repository is purpose-built to exploit vulnerable pac4j-jwt deployments that trust a PlainJWT when wrapped inside JWE.

This is a small standalone Python exploit repository containing one functional exploit script (`exploit.py`), a README, dependency list, license, and `.gitignore`. The exploit is not part of a larger framework. Its purpose is to produce a forged authentication token for a claimed pac4j JWT/JWE authentication bypass (CVE-2026-29000). The exploit workflow is straightforward: it builds an unsigned JWT with `alg: none`, inserts attacker-controlled claims such as `sub` and `role` (defaulting to `admin` / `ROLE_ADMIN`), then either fetches the target's public key material from JWKS endpoints or accepts a user-supplied JWKS via `--jwk`. It then encrypts the unsigned JWT into a compact JWE using `jwcrypto` with `RSA-OAEP-256` and `A128GCM`, and prints the final `Authorization: Bearer ...` token for manual use against protected endpoints. Key capabilities: - Automatic probing of two JWKS endpoints: `/.well-known/jwks.json` and `/api/auth/jwks` - Manual override of key material with `--jwk` - Customizable forged identity via `--username` - Customizable privilege claim via `--role` - Generation of a ready-to-use bearer token rather than sending follow-on exploitation requests itself The script does not include post-authentication automation, command execution, persistence, or shell payloads. It is an operational token-forging PoC focused on authentication/authorization bypass. The README provides extensive usage guidance, prerequisites, and example protected endpoints, but the actual code only generates and outputs the forged token.

Repository contains a single Python exploit script (exploit.py), a README, and license file. The exploit is a standalone operational proof-of-concept targeting CVE-2026-29000 in pac4j-jwt. Its stated workflow is: normalize and parse a supplied target URL, probe multiple common JWKS/JWK discovery paths, retrieve a public key, convert JWK material for use in token creation, forge an unsigned JWT with attacker-controlled claims, encrypt/wrap it as JWE, and submit it as a Bearer token to protected application endpoints. The tool also supports proxying, optional SSL verification, verbose logging, configurable retries, custom user-agent, token export, leak export, and optional keep-alive behavior. The repository structure is minimal and focused: README.md documents vulnerable versions, usage examples, and expected behavior; exploit.py implements the attack logic and CLI. The code defines a CVE202629000Exploit class with helper methods for target validation/parsing, logging, JWKS endpoint discovery, and runtime orchestration via a main() entry point using argparse. Primary exploit capability is authentication bypass against vulnerable pac4j-jwt deployments by abusing improper JWT/JWE validation and attacker-controlled claims. Secondary capability is post-auth enumeration of sensitive endpoints and collection of accessible data. Fingerprintable network indicators are mostly target-relative paths, especially JWKS discovery endpoints such as /.well-known/jwks.json, /oauth2/jwks, /realms/master/protocol/openid-connect/certs, and similar. Additional post-exploitation target paths shown in the repository include /api/users/me, /actuator/env, /api/users, /api/secrets, /config/server, /api/ping, and /api/admin/users. Based on the available code and documentation, this is not a detection-only script and not obviously fake; it is intended to actively exploit a vulnerable web application over HTTP(S).

This repository is a small standalone Python proof-of-concept consisting of one executable script (exploit.py) and a README. The exploit targets a web authentication design flaw involving nested JWT/JWE handling. Its workflow is straightforward: it accepts two command-line arguments, downloads the target's public RSA key from a JWKS endpoint using requests.get(), constructs an unsigned JWT whose header sets alg to none, populates the payload with hardcoded elevated claims (admin / ROLE_ADMIN / principal-platform), base64url-encodes the header and payload manually, and then encrypts that unsigned token into a compact JWE using jwcrypto with RSA-OAEP-256 and A128GCM. The resulting JWE is sent as a Bearer token to a user-supplied protected endpoint. If the target decrypts the JWE and trusts the inner JWT without verifying its signature, the script gains authenticated access and prints returned user details. The code has no framework affiliation, no persistence, and no post-exploitation logic; it is focused purely on authentication bypass via token forgery. Network interaction is limited to two outbound HTTP GET requests: one to retrieve JWKS data and one to access the protected resource with the forged Authorization header. The repository is therefore a real exploit PoC rather than a detector, with operational capability but limited customization beyond editing claims and headers manually.

Small standalone Python proof-of-concept repository for CVE-2026-29000 affecting pac4j-jwt. The repository contains one executable exploit script (CVE-2026-29000.py), a README describing the vulnerability and usage, and a GPL license. The exploit is not framework-based. Core capability: it performs authentication/authorization bypass by forging an unsigned inner JWT (alg=none) with attacker-chosen claims, then encrypting that JWT into a JWE using the target application's RSA public key obtained from a JWKS endpoint. Because vulnerable pac4j-jwt versions accept the decrypted inner PlainJWT without properly rejecting alg=none, the server may trust forged claims such as ROLE_ADMIN. Code structure: fetch_jwks() retrieves and validates JWKS JSON from a supplied path or full URL using requests; build_plain_jwt() constructs the unsigned JWT with sub, role, iss, iat, and exp claims; wrap_in_jwe() uses jwcrypto to create a compact JWE with RSA-OAEP-256 and configurable content encryption (A256GCM by default, optionally A128GCM); main() parses CLI arguments, resolves the JWKS URL, selects the first RSA key from the JWKS, generates the forged token, and prints instructions for using it in an Authorization header or browser session storage. The exploit does not automatically deliver the token to the target; instead it outputs a forged token for manual use. This makes it an operational PoC rather than a weaponized framework module. Fingerprintable target-related paths mentioned in code and documentation include /api/auth/jwks, /.well-known/jwks.json, /.well-known/openid-configuration, /robots.txt, and /static/js/app.js. The script also reveals expected token handling patterns such as Authorization: Bearer headers and sessionStorage key auth_token.

Small repository containing a single Python proof-of-concept exploit (cve.py), a README, and license file. The exploit targets CVE-2026-29000 in pac4j-jwt and is a real exploitation script rather than a detector. Its workflow is: validate the supplied target URL, request the target's public JWKS from /api/auth/jwks, parse the first RSA key, construct an unsigned JWT using alg=none with hardcoded admin-oriented claims, then wrap that JWT in a JWE using jwcrypto with RSA-OAEP-256 and A128GCM. The resulting Bearer token is used against /api/users and /api/settings to confirm successful authentication bypass and dump returned JSON data. The README explains the vulnerability as an authentication bypass caused by exposure of a public RSA key and acceptance of none-algorithm JWT handling, and notes that claim/header details were derived from /static/js/app.js. Overall, this is an operational web exploit for forging privileged session tokens against vulnerable pac4j-jwt-backed applications.

This repository is a small standalone Python proof-of-concept exploit for CVE-2026-29000 affecting pac4j-jwt. It contains two files: a single executable Python script (CVE-2026-29000.py) and a README with vulnerability background, prerequisites, usage, and remediation. The exploit is not part of a larger framework. The script's purpose is to exploit an authentication bypass in pac4j's handling of nested encrypted JWTs. It first requests the target's JWKS from /api/auth/jwks, extracts the first RSA public key, then constructs an unsigned inner JWT using alg=none with hardcoded administrative claims (sub=admin, role=ROLE_ADMIN, issuer principal-platform, and a one-hour validity window). It then encrypts that unsigned JWT into a JWE using jwcrypto with RSA-OAEP-256 and A128GCM, preserving the target key ID. Finally, it sends the resulting forged token as a Bearer token to /api/dashboard and prints the returned authenticated username/role and the forged token. Operationally, this is an authentication bypass and privilege-escalation exploit rather than code execution. It assumes the target application exposes a JWKS endpoint, uses pac4j-jwt in a vulnerable version, accepts nested JWE/JWT tokens, and trusts the decrypted inner JWT without enforcing signature validation. The payload is hardcoded and basic, so the repository is best classified as OPERATIONAL rather than weaponized.

This repository is a small standalone Python proof-of-concept exploit for CVE-2026-29000 affecting pac4j-jwt <= 6.0.3. The repo contains only two files: a README describing the vulnerability and usage, and exploit.py implementing the attack. The exploit is interactive: it prompts for a target base URL and a JWKS URL, retrieves the first RSA public key from the JWKS document via HTTP GET, then forges an unsigned inner JWT with alg:none and privileged claims (admin / ROLE_ADMIN). It wraps that unsigned token inside a JWE using jwcrypto with RSA-OAEP-256 and A128GCM, reusing the target key's kid value. The resulting compact JWE token is printed and written to forged_token.txt. The script does not directly send the forged token to the target; instead, it provides example curl commands for accessing protected endpoints such as /api/dashboard and /api/users. Overall, the exploit's purpose is authentication bypass through token forgery, leveraging public JWKS exposure and vulnerable pac4j-jwt handling of encrypted JWTs containing unsigned inner tokens.

This repository is a complete exploit lab and tooling set for CVE-2026-29000, described as a pac4j-jwt JWE authentication bypass. It is not tied to a common exploit framework; instead it contains: (1) a vulnerable Flask lab in lab/, (2) a reusable Python token forging library in token_forge/, (3) an interactive exploit console in scripts/exploit.py, (4) a Java in-process PoC in poc/, and (5) pytest coverage for the Python forging components in tests/. Core exploit capability: the Python and Java code forge a compact JWE using RSA-OAEP-256 and A256GCM with cty=JWT, but the encrypted plaintext is not a signed JWT. Instead it is a PlainJWT/unsigned token with alg=none and attacker-controlled claims. The forged claims include sub and $int_roles, allowing impersonation and privilege escalation to ROLE_ADMIN or ROLE_SUPERUSER. The Python library implements this in token_forge/claims.py, token_forge/jwe_builder.py, and token_forge/forge.py. token_forge/keys.py supports loading the target RSA public key from PEM or by fetching a JWKS URL over HTTP. The main exploit driver is scripts/exploit.py. It provides a Metasploit-style interactive console with options for RHOST, RPORT, SSL, PUBKEY, SUBJECT, ROLES, and TIMEOUT. It accepts the public key as a JWKS URL, local JWK file, or raw JWK JSON, then forges a malicious token and uses it in an Authorization Bearer header. The exploit script also contains an RCE stage tailored to the included lab: it calls /api/admin/diagnostics and injects shell metacharacters into the host parameter using a payload like 8.8.8.8; <cmd>. The vulnerable lab in lab/app.py simulates the target application. It generates or loads an RSA key, exposes public key material as JWKS, and provides protected endpoints including /api/profile and /api/admin/diagnostics. The diagnostics route is explicitly vulnerable because it executes ping -c 2 -W 1 {host} with shell=True, enabling command injection once admin access is obtained. The Docker lab writes a flag to /flag.txt and exposes the service on port 8080. The Java PoC in poc/src/main/java/Poc.java independently demonstrates the same bypass in-process against pac4j-jwt 6.0.3 using Nimbus JOSE and pac4j classes. It generates an RSA keypair, encrypts attacker-controlled claims with the public key, and validates that pac4j accepts the token. Overall, this is a real exploit repository rather than a detector. It provides both a reusable token forgery toolkit and a full exploit chain demonstration: reconnaissance of pac4j/JWKS, authentication bypass via JWE-wrapped unsigned JWT, privilege escalation through forged roles, and command execution against the intentionally vulnerable lab endpoint.

This is a small standalone Rust exploit repository for CVE-2026-29000, described as an authentication bypass in pac4j-jwt involving improper validation of a nested JWT. The repository contains 5 files total: a Rust manifest (Cargo.toml), one main source file (src/main.rs), a README, a gitignore, and a GitHub Actions workflow. The exploit logic is entirely concentrated in src/main.rs. The code uses reqwest and tokio for asynchronous HTTP access and josekit for JOSE/JWT/JWE handling. Its workflow is straightforward: it builds an HTTP client with a 3-second timeout and disabled certificate validation, requests the target JWKS from /api/auth/jwks, extracts the first RSA key's modulus (n), exponent (e), and key ID (kid), constructs an RSA JWK from those values, creates a JWT payload with issuer principal-platform, subject admin, role ROLE_ADMIN, and a long expiration window, then encodes that payload as an unsecured JWT using alg None. After that, it creates a JWE header using RSA-OAEP-256 and A128GCM, encrypts the unsecured inner JWT with the target's public key, and prints the resulting compact JWE token. The exploit does not directly send the forged token to an application endpoint; instead, it is a token generator intended to produce a malicious authentication artifact for later manual use. This makes it an operational exploit generator rather than a full end-to-end exploitation client. The main fingerprintable network target is the default base URL http://principal.htb:8080 and specifically the JWKS endpoint /api/auth/jwks. The README aligns with the code and explains the intended vulnerability mechanics: a server decrypts the outer JWE and incorrectly trusts the inner alg:none JWT without verifying a signature, enabling privilege escalation to admin.

This repository is a small standalone Python proof-of-concept exploit for CVE-2026-29000 affecting pac4j-jwt. The repository contains three files: an MIT LICENSE, a README with vulnerability background and usage instructions, and a single executable script, poc.py, which is the main exploit entry point. The exploit is not part of a larger framework. The PoC implements an authentication bypass against vulnerable pac4j-jwt deployments by forging an unsigned inner JWT with alg=none and attacker-controlled claims, then wrapping that token inside an encrypted JWE using the target server's RSA public key obtained from a JWKS endpoint. The script fetches the first key from the supplied JWKS URL, builds claims including sub, role, iss, iat, and exp, encrypts the inner token with RSA-OAEP-256 and A128GCM, and outputs the serialized token. It defaults to impersonating admin with role ROLE_ADMIN, but both values are user-configurable via command-line arguments. Operationally, the script supports two exploitation paths: direct network use and browser-assisted use. For network use, it can send the forged token in an Authorization: Bearer header to a user-supplied target URL and print the HTTP status and response body. For browser use, it prints a JavaScript snippet that stores the token in sessionStorage under auth_token, enabling manual access to a web application that reads authentication state from browser storage. Fingerprintable targets and indicators in the repository are mostly examples and expected deployment paths rather than hardcoded live infrastructure. The README documents /api/auth/jwks as the public key endpoint and /dashboard or /api/dashboard as protected resources. The code itself accepts arbitrary URLs via --jwks-url and --target, so the actual network endpoints are operator-supplied at runtime. Overall, this is a real exploit PoC rather than a detector. It provides practical token forgery capability and optional authenticated request testing, but it is still relatively simple and hardcodes a basic claim structure, making OPERATIONAL the best maturity assessment.

This repository is a small, single-purpose Python exploit PoC for CVE-2026-29000 against pac4j-jwt, accompanied by a README. The main file, CVE-2026-29000.py, is the only code file and serves as the entry point. It accepts a target base URL from the command line, retrieves the target's JWKS from /api/auth/jwks, extracts the first RSA public key, and then constructs an unsigned PlainJWT with hardcoded administrative claims. The script wraps that unsigned JWT inside a JWE encrypted with the server's public key using RSA-OAEP-256 and A128GCM, serializes it in compact form, and submits it as a Bearer token to /api/dashboard. If the target is vulnerable, the application accepts the forged token and returns dashboard/user data showing authentication as admin. The exploit is clearly offensive rather than diagnostic: it does not merely test for the issue, it actively forges credentials to bypass authentication and escalate privileges. The README explains that the PoC was tailored for the Hack The Box 'Principal' machine and notes that the JWKS endpoint, JWT claims, and verification endpoint are hardcoded and would need modification for other targets. Overall, the repository structure is minimal: one operational Python exploit plus documentation describing prerequisites, usage, and how to adapt the hardcoded target-specific values.

This repository is a small Python proof-of-concept exploit for CVE-2026-29000 affecting pac4j-jwt. It contains two executable scripts and a README. The main exploit is exp.py, which performs the full attack chain: it requests the target's JWKS from /api/auth/jwks, extracts the first RSA public key and kid, crafts an unsigned inner JWT using alg:none with attacker-controlled claims (default sub=admin and role=ROLE_ADMIN, plus iss=principal-platform and a 1-hour validity window), then encrypts that unsigned JWT into a compact JWE using RSA-OAEP-256 and A128GCM. The script finally sends the forged bearer token to /api/dashboard to confirm that the target accepts the nested token and authorizes the attacker as the claimed user. The companion script app.py is not the exploit primitive itself but an operator utility that reuses a forged token to query protected endpoints, either a user-specified path or a built-in list: /api/dashboard, /api/users, and /api/settings. Structurally, the repository is straightforward: README.md documents the vulnerability and usage, exp.py is the primary exploit entry point, and app.py is a post-exploitation/access-validation helper. The exploit is network-based, requires only HTTP access to the target application, and its main capability is authentication bypass with privilege escalation through forged JWT claims rather than code execution.

This repository is a small Python proof-of-concept for CVE-2026-29000 targeting applications that use the pac4j JWT module. It contains two files: a README describing the vulnerability and usage, and a single executable script, `poc.py`, which is the main exploit entry point. The script accepts a JWKS URL plus optional username and role values, retrieves the first public key from the remote JWKS document using `requests.get(args.jwks).json()["keys"][0]`, creates an unsigned JWT with `alg: none`, and embeds attacker-controlled claims including `sub`, `role`, `iss`, `iat`, and `exp`. It then encrypts that unsigned token into a compact JWE using `jwcrypto` with `RSA-OAEP-256` and `A128GCM`, setting `cty: JWT` and reusing the target key's `kid`. The final output is a malicious Bearer token intended to be supplied in an `Authorization: Bearer <token>` header. The exploit's core capability is authentication bypass and privilege escalation: it forges arbitrary identities and roles without needing a private signing key, relying only on access to the target's public JWKS endpoint and the vulnerable server-side parsing behavior that accepts a JWE containing an unsigned inner PlainJWT. This is a real exploit PoC rather than a detector, and while simple, it is operational because it produces a usable malicious token directly.

This is a very small Python proof-of-concept repository containing a single exploit script (poc.py), a minimal requirements file, and a short README. The script is not a scanner or detector; it actively forges an authentication token for CVE-2026-29000. Its core behavior is: load an RSA public key from the local file key.pub, build a JWT payload with privileged claims (sub=admin, role=ROLE_ADMIN, iss=principal-platform, and a 1-hour validity window), encode that JWT using alg=none to produce an unsigned token, then wrap that unsigned JWT inside an encrypted JWE using RSA-OAEP and A256GCM via jwcrypto. The final output is a serialized forged JWE token printed to stdout. There are no hardcoded remote URLs, IPs, or direct network requests in the exploit itself; it is an offline token-forging utility intended to produce a bearer token for later use against a vulnerable pac4j-based application. The main capability is authentication/authorization bypass by crafting an encrypted token that may be accepted as valid if the target mishandles JWT/JWE verification. The repository structure is straightforward: README.md documents the claimed CVE and links to external research, requirements.txt lists pyjwt and jwcrypto, and poc.py is the sole executable entry point.

This repository is a small Python proof-of-concept exploit for CVE-2026-29000 targeting pac4j-jwt authentication handling. It contains only two files: a README with example usage and exploit.py, the sole executable component. The script takes a base target URL as its only argument, performs a GET request to /api/auth/jwks to retrieve the server's RSA public key, constructs an unsigned JWT with alg=none and hardcoded elevated claims (sub=admin, role=ROLE_ADMIN, iss=principal-platform), then encrypts that plaintext JWT into a compact JWE using the retrieved public key via jwcrypto with RSA-OAEP-256 and A128GCM. It finally sends the forged token in an Authorization Bearer header to /api/dashboard and prints the returned user identity and role, demonstrating successful authentication bypass and privilege escalation. The exploit is operational rather than a mere detector because it actively forges a usable token and attempts authenticated access. There is no framework usage, no modular structure, and no persistence or post-exploitation logic beyond obtaining admin-level API access.

Repository purpose: a Dockerized, library-level proof-of-concept lab for CVE-2026-29000 affecting pac4j-jwt’s JwtAuthenticator. It is not a network exploit server; instead it programmatically generates and validates tokens to demonstrate vulnerable-versus-patched behavior. Structure (5 files): - src/main/java/lab/Repro.java: main PoC harness. Generates an RSA keypair, builds a legitimate token, forges an attacker token with configurable subject/roles, then validates both through JwtAuthenticator using RSA encryption + RSA signature configurations. It prints results and exits non-zero if behavior doesn’t match expectations. - pom.xml: Maven project that builds a shaded runnable JAR (mainClass lab.Repro). pac4j-jwt version is controlled via env var PAC4J_VERSION; includes nimbus-jose-jwt for JOSE/JWT/JWE construction. - docker-compose.yml: defines a test matrix with three services (v603, v6041, patched) that build/run the same code against pac4j-jwt 6.0.3, 6.0.4.1 (expected vulnerable), and 6.3.3 (expected fixed). - Dockerfile: multi-stage build (Maven -> JRE) producing /app/app.jar and running it. - README.md: explains expected outputs: baseline token accepted everywhere; forged token accepted on vulnerable versions producing an authenticated profile with attacker-controlled subject/roles; forged token rejected on 6.3.3. Exploit capability: token forgery leading to authentication/profile creation with attacker-controlled identity and roles (authorization impact depends on how an application maps roles/claims). No hardcoded external C2/network endpoints; all operations are local token generation/validation within the JVM.

Repository provides an operational exploit toolkit for CVE-2026-29000 (pac4j-jwt JwtAuthenticator auth bypass). Core capability is forging a JWE token that encrypts an unsigned PlainJWT (alg=none) so that vulnerable pac4j-jwt deployments skip signature verification after JWE decryption, allowing attacker-controlled claims (sub, $int_roles, exp, and arbitrary extras) and thus impersonation of any user/role using only the server’s RSA public key. Structure/purpose: - token_forge/ (Python): Implements token forging. - claims.py builds claims and serializes a 2-part PlainJWT with header {alg:none}. - jwe_builder.py wraps the PlainJWT into compact JWE using RSA-OAEP-256 + A256GCM with cty=JWT. - keys.py loads RSA public key from PEM or fetches JWKS via HTTP(S) (requests.get) and selects an RSA key (optionally by kid). - cli.py exposes a CLI (python -m token_forge) to output a single forged token line; supports subject, roles, exp-sec, and extra claims. - log_config.py provides colored console logging and optional JSON/grepable file logs. - scripts/kr_scan.py (Python): Automation that forges a token then runs kiterunner (default path ~/bin/kr) with header "Authorization: Bearer <token>" to brute/scan for protected API routes; supports wordlists, Assetnote lists, output formats, timeouts, and dry-run. - poc/ (Java/Maven): In-process PoC against pac4j-jwt 6.0.3 demonstrating bypass by generating a JWE containing raw claims JSON (unsigned) and validating via JwtAuthenticator configured with both RSA encryption and RSA signature configs. - lab/ (Flask): Local vulnerable-style service exposing /.well-known/jwks.json and /api/me to test forging end-to-end; decrypts JWE and returns claims without signature verification. - examples/ (bash): Convenience scripts to forge and curl a URL or run kr_scan. - tests/: Pytest coverage for claim serialization, key loading, CLI behavior, and kr_scan command construction. Overall, this is an exploit (not just detection): it produces a usable authentication token payload and includes tooling to apply it against network targets and enumerate authenticated endpoints.