REDHAT-BUG-2527936: Medium severity GStreamer GStreamer vulnerability
gst-plugins-base's RTSP support library (subprojects/gst-plugins-base/gst-libs/gst/rtsp/gstrtspmessage.c) implements gstrtspmessageparseauthcredentials(), used by both gst-rtsp-server (to parse a client's Authorization header, gst-rtsp-server/gst/rtsp-server/rtsp-auth.c:861, defaultauthenticate()) and by RTSP clients such as gstrtspsrc (gst-plugins-good/gst/rtsp/gstrtspsrc.c:6966) and rtspclientsink (gst-rtsp-sink/gstrtspclientsink.c:2737) to parse a server's WWW-Authenticate header. The internal helper parseauthcredentials() (gstrtspmessage.c, static function, ~line 1362) tokenizes comma-separated auth-param name=value pairs. For each parameter it computes itemend = skipitem(header) (the end of the current token, which points AT the whitespace/comma/NUL character that terminated the token, not past it), then does value = skiplws(eq + 1); authparam->value = gstrndup(value, itemend - value); (line ~1421-1425). skiplws() has no awareness of itemend: if the character skipitem() used as the token terminator happens to be whitespace, skiplws() will step over it (and any further whitespace) looking for a non-space character, potentially advancing value past itemend. This makes itemend - value a negative ptrdifft, which is implicitly converted to gsize (an unsigned 64-bit value near GMAXSIZE) when passed to gstrndup(). Because n+1 (computed inside gstrndup) wraps to 0 on the -1 case, gnew(gchar, 0) resolves to gmalloc(0), which by GLib's documented contract returns NULL; strncpy() is then invoked with this NULL destination and n=GMAXSIZE, corrupting/crashing, and even where gstrndup does return, the resulting NULL is stored into authparam->value without a NULL check. Immediately afterward the code does if (value[0] == '"') decodequotedstring(authparam->value); -- value[0] here is checked on the original (non-NULL) source pointer, so the branch can be taken even though authparam->value is NULL, and decodequotedstring() dereferences the NULL pointer, causing SIGSEGV. Reporter (Roy Lau, royworking98) reported this to the GStreamer security contacts on 2026-08-26 (gitlab.freedesktop.org/gstreamer/gstreamer/-/workitems/5278), and the maintainers merged a fix at gitlab.freedesktop.org/gstreamer/gstreamer-security/-/mergerequests/120 on 2026-09-02, targeting the 1.28.7 release. Reporter tested against gstreamer <= 1.28.2; the vulnerable code path is present up to (and reportedly including) versions prior to 1.28.7. Verified independently via static source review against the 1.28.2 tag; dynamic PoC execution was not performed. PSIRT Ticket: PSIRTSUPT-23042 (GST-SA-2026-0082).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
gstreamer/gstreamerto a version that resolves this vulnerability.Fixed in 1.28.7Patch PSIRTSUPT-23042 (GST-SA-2026-0082) - Configuration
Apply the merged security fix (PSIRTSUPT-23042 / GST-SA-2026-0082) to ensure auth_param->value is checked for NULL before evaluating value[0] and before calling decode_quoted_string() in parse_auth_credentials (gstrtspmessage.c ~1421-1425, ~1362).
GStreamer RTSP auth parsing (gstrtspmessage.c: parse_auth_credentials / gst_rtsp_message_parse_auth_credentials) NULL-check for auth_param->value before accessing value[0] and before decode_quoted_string() = Add/ensure NULL guard so decode_quoted_string() is called only when auth_param->value is non-NULL - Compensating control
If you cannot upgrade immediately, limit exposure of RTSP parsing to trusted clients/paths (e.g., restrict access to RTSP endpoints that process Authorization/WF-Authenticate headers) to reduce the likelihood of triggering the NULL dereference in RTSP authentication credential parsing.
Event History
Frequently Asked Questions
Which deployments can receive attacker-controlled input through the affected parser?
RTSP servers using gst-rtsp-server can process a client's Authorization header through this parser. RTSP clients using gstrtspsrc or rtspclientsink can process a server's WWW-Authenticate header through the same parser.
What would an attacker need to control?
An attacker would need to supply a specially formed RTSP authentication header containing comma-separated authentication parameters. For servers this is an Authorization header sent by a client; for clients it is a WWW-Authenticate header sent by an RTSP server.
Is the server-side default authentication path involved?
Yes. The affected parsing function is used by gst-rtsp-server's default_authenticate() path when it parses a client's Authorization header.