Almost certainly a false positive.

Yes, googling CVE-2023-0247 you'll be able to observe that it's about a Go repo

I'm still learning how to figure out why nvd determines a lib could be problematic. There are several nvd reports generated, the last time I looked, iirc, the xml report gives even more details than the html report and can help.

I once asked at https://github.com/jeremylong/DependencyCheck (nvd's core dep) why is it so wonky. I didn't get a convincing answer other than 'we're improving it with each release' I think it got some qualitative improvement some major versions ago. But since then, I think it's all been hardcoded exceptions There's some change that DependencyCheck has some sort of flawed design. However if you check the official CVE pages from NIST, you might agree that their format doesn't exactly lend itself to laser-accurate matching.

It would all be so simple if NIST simply used maven coordinates (or coordinates from whatever lang ecosystem is affected). But they stick to their format. It's a common mistake in programming IMO - 'unifying' things that shouldn't.

Thanks @U45T93RA6, yeah I figure they feel it is better to report a potential match than to not report at all. For example, I was getting jsch.agentproxy.usocket-nc-0.0.9 flagged. I concluded it was matching several netcat CVEs because the lib description included https://github.com/clj-commons/pomegranate/blob/4db42b2091f363bff48cbb80bc5230c3afa598d9/nvd_check_helper_project/suppressions.xml#L5-L15. It would be helpful if the reports presented very clearly why a lib is flagged. But hey, this is open source, so just thankful the tool (and clojure wrapper!) exists.

cljs.user=> (clojure.string/replace "Adam" (js/RegExp. "(a)" "iu") "$1+")
"A+da+m"

oh so just put it in parenthesis. thank you!