You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to bring to your attention a potential log injection vulnerability found in version 2.2.0 of the project. Below are the details of the issue:
What happened?
In the file OsgiRegistry.java, there is a potential Log Injection Vulnerability in the method call().
The code is logging data that is derived from an external source (providerClassName) without proper validation or sanitization. This allows for a log injection attack, where malicious content from external inputs could be injected into the log entries. To learn more check CWE-117.
What did we expect to happen?
The expectation is that any data originating from untrusted external sources (like file inputs) would be sanitized or validated before being used in sensitive areas like logging systems to prevent attackers from manipulating log contents.
How can we reproduce it (as minimally and precisely as possible)?
This issue is identified through static analysis, so it cannot be directly reproduced via runtime observation. However, if left unresolved, it could lead to unpredictable behavior in environments where recursive read locks are not supported.
Sponsorship and Support:
This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.
The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory, Inc. and then manually triaging the results.
The text was updated successfully, but these errors were encountered:
@Sawraz-OpenRef Thank you for coming up with a possible CVE to us.
This indeed looks like an issue, the call method loads classes from a URL passed to the spiRegistryUrl string.
However, this URL string is taken from META-INF/services, which is in a file bundle on the local file system.
Can you elaborate more on the potential vulnerability in this case? The bundles on the local file system are only provided by the customer, who uses Tyrus and OsgiRegistry class.
I apologize for the confusion caused by my previous bug report. This bug report was generated as part of a static analysis process. I appreciate your clarification on the matter, and this insight will help improve future scan results to avoid similar false positives.
Hi Team,
I would like to bring to your attention a potential log injection vulnerability found in version 2.2.0 of the project. Below are the details of the issue:
What happened?
In the file OsgiRegistry.java, there is a potential Log Injection Vulnerability in the method
call()
.The code is logging data that is derived from an external source (
providerClassName
) without proper validation or sanitization. This allows for a log injection attack, where malicious content from external inputs could be injected into the log entries. To learn more check CWE-117.What did we expect to happen?
The expectation is that any data originating from untrusted external sources (like file inputs) would be sanitized or validated before being used in sensitive areas like logging systems to prevent attackers from manipulating log contents.
How can we reproduce it (as minimally and precisely as possible)?
This issue is identified through static analysis, so it cannot be directly reproduced via runtime observation. However, if left unresolved, it could lead to unpredictable behavior in environments where recursive read locks are not supported.
Sponsorship and Support:
This work is done by the security researchers from OpenRefactory and is supported by the Open Source Security Foundation (OpenSSF): Project Alpha-Omega. Alpha-Omega is a project partnering with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code - and get them fixed – to improve global software supply chain security.
The bug is found by running the Intelligent Code Repair (iCR) tool by OpenRefactory, Inc. and then manually triaging the results.
The text was updated successfully, but these errors were encountered: