Headline
CVE-2021-27568: Uncaught Exception in Parser · Issue #60 · netplex/json-smart-v2
An issue was discovered in netplex json-smart-v1 through 2015-10-23 and json-smart-v2 through 2.4. An exception is thrown from a function, but it is not caught, as demonstrated by NumberFormatException. When it is not caught, it may cause programs using the library to crash or expose sensitive information.
Ok, I dug a bit. MITRE rated it like this:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Attack Vector: None, Attack Complexity: Low, Privileges Required: None, User Interaction: None, Scope: Unchanged, Confidentiality: High, Integrity: None, Availability: High.
I would have scored it the same except for Confidentiality: High. I guess that’s because of the potential for a stack trace getting returned to the end user? But this bug does not guarantee that a stack trace is returned to the user, for that the library would have to be used by an application returns unexpected stack traces to the user in a 500 body, which well-behaved apps should not be doing anyways. If that understanding is correct, I would have called this Confidentiality: Low or None, which would have given a Base Score of 8.2 or 7.5 respectively – which are out of the Critical range.
There may also be wiggle-room on Availability: High. This bug does not guarantee that the application crashes; that would only be the case if the calling application does not have a generic catch (Exception e) anywhere in the call stack and this NumberFormatException gets all the way back to the JRE, which again is probably uncommon in well-behaved apps that parse user input. Availability: Low might be a better rating?
I’m making a fuss because 9.0 - 10.0 is Critical, and having those show up can trigger emergency patching policies or delays to release schedules. Is it possible to ask MITRE to re-evaluate the scoring of this issue?