Conversation

oh, the gitlab vulnerability was "we're passing user input to Regexp.new and ruby doesn't consider that to be a security vuln if that causes issues"?

https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/

However, the Regexp documentation currently discusses untrusted patterns only in terms of denial of service, and recommends a timeout for them. It does not clearly say whether compiling an untrusted pattern is a use case that Ruby supports. We plan to discuss how to document this, and whether we treat this kind of issue as a vulnerability in Ruby, including whether to request CVE identifiers for these fixes.

... at the very least they should probably put big scary warnings of "this is NOT CONSIDERED SAFE to pass user input to". but ideally consider hostile regexes to be in-scope for security reasons since it's really not that weird to have attacker provided regexes in things...

1
0
0

@5225225 i think at an absolute minimum the regex partner should not fail in a way that can be exploited by an attacker past resource exhaustion

1
0
2

@charlotte mhm

Regexp.new(completely_arbitrary_regex) OOMing or stack overflowing or taking arbitrary amounts of time would be... fine. unpleasant, still a DoS, but not potential RCE

(but also, yeah, reasonable limits such that the average system will return an error instead of crashing would be nice too, and ruby has some of that)

0
0
0