Skip to content

Conversation

@hudakh
Copy link
Contributor

@hudakh hudakh commented Dec 17, 2025

CVE-2025-58767 advisory rubies/ruby/CVE-2025-58767

@postmodern
Copy link
Member

We already have this advisory as gems/rexml/CVE-2025-58767.yml. Also, the patched_versions mentions 3.2.10 and 3.3.11, except I don't believe Ruby 3.2.10 or 3.3.11 were ever released.

@postmodern postmodern closed this Dec 17, 2025
@hudakh
Copy link
Contributor Author

hudakh commented Dec 17, 2025

We already have this advisory as gems/rexml/CVE-2025-58767.yml. Also, the patched_versions mentions 3.2.10 and 3.3.11, except I don't believe Ruby 3.2.10 or 3.3.11 were ever released.

Thanks for the review.

I wanted to clarify the rationale for adding a rubies/ruby entry in this case.

After checking the repository, there are already multiple CVEs that exist in both rubies/ruby and gems/*, for example:

CVE-2009-4492
CVE-2017-10784
CVE-2017-14033
CVE-2018-16395
CVE-2020-10663
CVE-2021-33621
CVE-2025-24294
CVE-2025-61594

These duplicates suggest that the repository has historically represented some vulnerabilities at both the Ruby implementation level and the gem level, particularly for bundled stdlib components. You reviewed the last two for me too!

Is the current policy is to avoid new duplication? If that’s the case, it might be helpful to document this expectation (or clean up existing duplicates) to avoid future confusion.

Please let me know how you’d prefer to handle this going forward.

As for ruby 3.2.10 and 3.3.11, the PRs to update the gem in ruby 3.2 and 3.3 have been merged, but new versions of ruby haven't been released yet. I added this in the notes section as I wasn't sure how to handle it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants