gss-ntlmssp (gssapi/gss-ntlmssp) contains a memory leak in the NTLM CHALLENGE target-info parsing on the client (initiator) path. The function ntlm_decode_av_pair_u16l_str() in src/ntlm.c (line 444) allocates a buffer via malloc and assigns it to *str (line 464) without freeing any previous value. The caller ntlm_decode_target_info() (line 637) iterates over AV_PAIRs in a while loop and decodes each string-valued AV_PAIR (MSV_AV_NB_COMPUTER_NAME, MSV_AV_NB_DOMAIN_NAME, MSV_AV_DNS_COMPUTER_NAME, MSV_AV_DNS_DOMAIN_NAME, MSV_AV_DNS_TREE_NAME, MSV_AV_TARGET_NAME) into local variables. If a CHALLENGE message contains a duplicated string-valued AV_PAIR ID, the second call overwrites the local pointer without freeing the first allocation. The done: cleanup only frees the last value held. The acceptor path (gss_sec_ctx.c:843) passes NULL for all six string out-parameters, so the leak does not fire server-side. The initiator path is reachable via ntlm_process_target_info() (src/ntlm.c:765), called from gssntlm_cli_auth() in src/gss_auth.c:85, which passes all six string parameters non-NULL. The unguarded allocation predates the February 2023 security batch (GHSL-2023-011/012/013) and was not caught because oss-fuzz drives the acceptor entry point which never runs the string decode. By inspection, all released versions are affected. Reported by Chase Bevan-Thomas (cbev0x), independent security researcher. No upstream fix available at time of report. PSIRT Ticket: PSIRTSUPT-23614. Verified via static analysis in Kaiden sandbox.