diff --git a/crates/pam-bindings/RUSTSEC-0000-0000.md b/crates/pam-bindings/RUSTSEC-0000-0000.md
new file mode 100644
index 0000000000..d231d05c18
--- /dev/null
+++ b/crates/pam-bindings/RUSTSEC-0000-0000.md
@@ -0,0 +1,33 @@
+```toml
+[advisory]
+id = "RUSTSEC-0000-0000"
+package = "pam-bindings"
+date = "2026-04-08"
+url = "https://github.com/anowell/pam-rs/issues/16"
+references = ["https://github.com/Uberspace/pam_isolate#5"]
+categories = ["privilege-escalation"]
+keywords = ["pam"]
+
+[affected.functions]
+# workaround rustsec/rustsec#1575
+# "pam::module::PamHandle::get_user" = [">= 0.0.0"]
+
+[versions]
+patched = []
+```
+
+# PAM get_user can return PAM_SUCCESS and bypass authentication in release builds
+
+This line here:
+
+[pam-rs/pam/src/module.rs](https://github.com/anowell/pam-rs/blob/3d9318b5b812d9142595928deec23e5843a60995/pam/src/module.rs#L195) Line 195 in 3d9318b
+
+```rs
+let res = unsafe { pam_get_user(self, &ptr, c_prompt) };
+```
+
+is unsound. It passes an immutable reference to a Rust variable to the function, which then tries to mutate it. In my project, this works fine in debug mode, but fails in release mode.
+
+Particularly with idiomatic usage `pam_try!(pamh.get_user(None))` this silently returns PAM_SUCCESS in *release* builds typically bypassing any authentication.
+
+Even though the crate seems unmaintained, it seems to remain one of the most widely used PAM module bindings. The above mentioned bug can be found in numerous PAM module repos.