{"answers":{"affected":"1 open source package ship an affected version, including bcrypt.","exploited":"There is no known exploitation of RUSTSEC-2026-0199 in the wild and no public exploit code.","fix":"Upgrade bcrypt to 0.19.2 or later.","what":"RUSTSEC-2026-0199 is a denial of service vulnerability in bcrypt, published on 20 Jun 2026. An attacker can exploit it over the internet without logging in, with no action from the victim."},"fix_prompt":"Check this codebase for RUSTSEC-2026-0199 and fix it if it is affected.\n\nWhat it is: RUSTSEC-2026-0199 is a denial of service vulnerability in bcrypt, published on 20 Jun 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.\nExploitation: There is no known exploitation of RUSTSEC-2026-0199 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- bcrypt (crates.io): affected from 0.19.0; fixed in 0.19.2\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/RUSTSEC-2026-0199/ (Markdown: https://insights.sbomify.com/RUSTSEC-2026-0199/index.md)","id":"RUSTSEC-2026-0199","markdown":"https://insights.sbomify.com/RUSTSEC-2026-0199/index.md","name":"RUSTSEC-2026-0199","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["denial_of_service"],"network_reachable":"yes","non_default_config":false,"product_category":"Rust bcrypt library","requires_auth":"none","summary":"Attackers can crash Rust applications by supplying non-ASCII bcrypt hashes, causing a panic in the verification logic.","user_interaction":"not_required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"`bcrypt::verify(password, hash)` and `HashParts::from_str(hash)` panic in\n`str::slice_error_fail` when given a 60-byte `\u0026str` containing a multi-byte\nUTF-8 character at certain byte positions.\n\n## Impact\n\nAny Rust code that calls `bcrypt::verify` (or `HashParts::from_str`) with an\nattacker-controlled hash string will panic. The `bcrypt` crate is\n`#![forbid(unsafe_code)]`, so this is limited to a denial-of-service and\ncannot lead to memory corruption.\n\nRealistic attack contexts include:\n\n- Rust authentication services reading hashes from a database that was\n  previously compromised via, e.g., SQL injection. The attacker can then\n  crash the service on every login attempt against the tampered account.\n- CLI tools accepting hashes from stdin or command-line arguments.\n- Password managers or vault services loading hashes from untrusted\n  configuration sources.\n\n## Root cause\n\n`split_hash` performed five `\u0026str` slicing operations on the input hash:\n`\u0026hash[1..3]`, `\u0026hash[4..6]`, `\u0026hash[7..]`, `\u0026salt_and_hash[..22]`, and\n`\u0026salt_and_hash[22..]`. None of these were char-boundary-checked. Any input\nwhere a multi-byte UTF-8 character spanned one of those byte positions\ncaused a panic.\n\nThis is a regression of the fix originally shipped in 2021 for issue #62\n(commit `0833509`). The regression was introduced in the parser rewrite in\nPR #95 (commit `e9a8394`, released as 0.19.0).\n\nThe pre-existing regression test `does_no_error_on_char_boundary_splitting`\nwas not removed, but was silently rendered ineffective by the new\n`bytes[0] != b'$'` guard, which rejected its input earlier and prevented\nit from reaching the buggy slices — leaving CI green through the regression.\n\n## Fix\n\n`split_hash` now rejects any hash string containing non-ASCII bytes up\nfront. A valid bcrypt hash is always exactly 60 ASCII bytes, so this\ncloses the entire class of byte-boundary panics rather than guarding each\nslice individually.\n\nThe fix was merged in PR #103 and released as `bcrypt 0.19.2` on 2026-06-20.\n\n## Downstream impact\n\n`pyca/bcrypt` (which depended on `bcrypt 0.19.1`) is **not** affected. Its\nPython-side wrapper performs its own byte-level salt parsing before\ninvoking `bcrypt::hash_with_salt`, and never reaches the buggy code path\nin `split_hash` or `verify`.","ecosystems":["crates.io"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Panic in `bcrypt::verify` on non-ASCII hash input","id":"RUSTSEC-2026-0199","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"crates.io","product":null,"products":[],"type":"denial_of_service","year":"2026"},"n_packages":1,"n_references":null,"packages":[{"ecosystem":"crates.io","fixed":["0.19.2"],"introduced":["0.19.0"],"last_affected":[],"package":"bcrypt","purl":"pkg:cargo/bcrypt","source":"RUSTSEC-2026-0199"}],"products":null,"published":"2026-06-20","related":[],"sources":[{"class":"open","licence":"CC0 1.0","name":"RustSec","prefix":"RUSTSEC"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Attackers can crash Rust applications by supplying non-ASCII bcrypt hashes, causing a panic in the verification logic.","url":"https://insights.sbomify.com/RUSTSEC-2026-0199/"}