Ruby through 2.4.7, 2.5.x through 2.5.6, and 2.6.x through 2.6.4 allows code injection if the first argument (aka the "command" argument) to Shell# or Shell#test in lib/shell.rb is untrusted data. An attacker can exploit this to call an arbitrary Ruby method.
(Note that the Severity noted in the report is "None (0.0)". It also took upstream 15+ months to create patch since the initial acknowledgement of the report.)
Upstream commit in the Ruby git:
Upstream commit in the Ruby Shell git:
This issue was fixed in Ruby 2.6.5, 2.5.7, and 2.4.8:
This flaw exists in the Shell module in the Ruby standard library, specifically in the test() /  method (the two names are aliases for the same method). This method accepts two or three arguments - command and one or two file names. However, this method is rather poorly documented, with documentation not explaining what the command argument is supposed to be:
"Tests if the given command exists in file1, or optionally file2."
The Shell#test() method is a wrapper around FileTest, which implements various file-related tests, such as checks for file existence and type, file permissions, or size:
The command passed to the Shell#test is supposed to be a FileTest's method to be called. The Shell#test can be used as:
sh = Shell.new
# does /etc exist?
# is /etc a regular file?
# is /etc a directory?
# what is /etc's size?
The problem tracked via this CVE is that the Shell#test implementation allowed calling not only methods directly implemented by the FileTest, but also methods inherited from the parent classes. These methods may be used to achieve arbitrary code execution.
However, this problem can only have security implications in situations when untrusted input is directly passed to Shell#test as its command argument. Additionally, untrusted file name value is also required to provide the right payload to the method called via the command argument. Such use cases seem rather unlikely and may also indicate another problem in the Ruby application. Upstream advisory notes:
Note that passing untrusted data to methods of Shell is dangerous in general. Users must never do it. However, we treat this particular case as a vulnerability because the purpose of Shell# and Shell#test is considered file testing.
This problem would affect very few applications, if any. The original HackerOne report does not indicate any real-world application exposing this problem.
Lowering impact rating based on the information above - while this in theory has high impact (arbitrary code execution), it's rather unlikely to be a problem in any relevant real-world use case.