ghsa

Core creation allows users to replace "trusted" configset files with arbitrary configuration Solr instances that (1) use the "FileSystemConfigSetService" component (the default in "standalone" or "user-managed" mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual "trusted" configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem.  These replacement config files are treated as "trusted" and can use "<lib>" tags to add to Solr's classpath, which an attacker might use to load malicious code as a searchComponent or other plugin. This issue affects all Apache Solr versions up through Solr 9.7.  Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from "FileSystemConfigSetService").  Users are also recommended to upgrade to Solr 9.8.0, which mitigates this ...

### Impact In CI contexts, the IG Publisher CLI uses git commands to determine the URL of the originating repo. If the repo was cloned, or otherwise set to use a repo that uses a username and credential based URL, the entire URL will be included in the built Implementation Guide, exposing username and credential. This does not impact users that clone public repos without credentials, such as those using the auto-ig-build continuous integration infrastructure. ### Patches This problem has been patched in release [1.8.9](https://github.com/HL7/fhir-ig-publisher/releases/tag/1.8.9) ### Workarounds Users should update to 1.8.9 or the latest release OR Users should ensure the IG repo they are publishing does not have username or credentials included in the `origin` URL. Running the command `git remote origin url` should return a URL that contains no username, password, or token. OR Users should run the IG Publisher CLI with the `-repo` parameter and specify a URL that contains no us...

### Summary If an attacker can control the input to the `asteval` library, they can bypass asteval's restrictions and execute arbitrary Python code in the context of the application using the library. ### Details The vulnerability is rooted in how `asteval` performs handling of `FormattedValue` AST nodes. In particular, the [`on_formattedvalue`](https://github.com/lmfit/asteval/blob/cfb57f0beebe0dc0520a1fbabc35e66060c7ea71/asteval/asteval.py#L507) value uses the [dangerous format method of the str class](https://lucumr.pocoo.org/2016/12/29/careful-with-str-format/), as shown in the vulnerable code snippet below: ```py def on_formattedvalue(self, node): # ('value', 'conversion', 'format_spec') "formatting used in f-strings" val = self.run(node.value) fstring_converters = {115: str, 114: repr, 97: ascii} if node.conversion in fstring_converters: val = fstring_converters[node.conversion](val) fmt = '{__fstring__}' if node.f...

### Summary Private maven repository credentials leaked in application logs in case of unsuccessful retrieval operation. ### Details During the execution of an updatecli pipeline which contains a `maven` source configured with basic auth credentials, the credentials are being leaked in the application execution logs in case of failure. Credentials are properly sanitized when the operation is successful but not when for whatever reason there is a failure in the maven repository .e.g. wrong coordinates provided, not existing artifact or version. ### PoC The [documentation](https://www.updatecli.io/docs/plugins/resource/maven/) currently state to provide user credentials as basic auth inside the `repository` field. e.g. ``` sources: default: kind: maven spec: repository: "{{ requiredEnv "MAVEN_USERNAME" }}:{{ requiredEnv "MAVEN_PASS" }}@repo.example.org/releases" groupid: "org.example.company" artifactid: "my-artifact" versionFilter: kind: ...

### Impact summary In some circumstances, debug artifacts uploaded by the CodeQL Action after a failed code scanning workflow run may contain the environment variables from the workflow run, including any secrets that were exposed as environment variables to the workflow. Users with read access to the repository would be able to access this artifact, containing any secrets from the environment. For some affected workflow runs, the exposed environment variables in the debug artifacts included a valid `GITHUB_TOKEN` for the workflow run, which has access to the repository in which the workflow ran, and all the permissions specified in the workflow or job. The `GITHUB_TOKEN` is valid until the job completes or 24 hours has elapsed, whichever comes first. Environment variables are exposed only from workflow runs that satisfy all of the following conditions: - Code scanning workflow configured to scan the Java/Kotlin languages. - Running in a repository containing Kotlin source code. - R...

### Impact XSLT transforms performed by various components are vulnerable to XML external entity injections. A processed XML file with a malicious DTD tag ( ]> could produce XML containing data from the host system. This impacts use cases where org.hl7.fhir.publisher is being used to within a host where external clients can submit XML. A previous release provided an incomplete solution revealed by new testing. ### Patches This issue has been patched as of version 1.7.4 ### Workarounds None ### References [Previous Advisory for Incomplete solution](https://github.com/HL7/fhir-ig-publisher/security/advisories/GHSA-59rq-22fm-x8q5) [MITRE CWE](https://cwe.mitre.org/data/definitions/611.html) [OWASP XML External Entity Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#transformerfactory)

Cross Site Scripting vulnerability in nbubna store v.2.14.2 and before allows a remote attacker to execute arbitrary code via the store.deep.js component

### Impact Directus allows an authenticated attacker to save cross site scripting code to the database. This is possible because the application injects an attacker-controlled parameter that will be stored in the server and used by the client into an unsanitized DOM element. When chained with [CVE-2024-6534](https://github.com/directus/directus/security/advisories/GHSA-3fff-gqw3-vj86), it could result in account takeover. ### PoC To exploit this vulnerability, we need to do the following steps using a non-administrative, default role attacker account. 1. Upload the following JavaScript file. Using the upload functionality at `POST /files`. This PoC will show an alert message. ```js export TARGET_HOST="http://localhost:8055" export ATTACKER_EMAIL="[email protected]" export ATTACKER_PASSWORD="123456" root_dir=$(dirname $0) mkdir "${root_dir}/static" curl -s -k -o /dev/null -w "%{http_code}" -X 'POST' "${TARGET_HOST}/auth/login" \ -c "${root_dir}/static/attacker_directus_se...

### Summary When sharing an item, user can specify an arbitrary role. It allows user to use a higher-privileged role to see fields that otherwise the user should not be able to see. ### Details Specifying `role` on share should be available only for admins. The current flow has a security flaw. Each other role should allow to share only in the context of the same role. As there is no role hierarchy in Directus, it is impossible to tell which role is _higher_ or _lower_, so only admins should be able to specify the role for share. Optionally, instead of specifying a role, shareer* should be able to specify which fields (limited to fields shareer sees) are available on shared item. Similarily to import. *_shareer_ - a person that creates a share link to item ### PoC 1. Create a collection with a secret field. 2. Create role A that sees the secret field 3. Create role B that does not see the secret field, but can use share feature. 4. Create item with secret field filled. 5. Use ac...

### Summary If an attacker can control the input to the asteval library, they can bypass its safety restrictions and execute arbitrary Python code within the application's context. ### Details The vulnerability is rooted in how `asteval` performs attribute access verification. In particular, the [`on_attribute`](https://github.com/lmfit/asteval/blob/8d7326df8015cf6a57506b1c2c167a1c3763e090/asteval/asteval.py#L565) node handler prevents access to attributes that are either present in the `UNSAFE_ATTRS` list or are formed by names starting and ending with `__`, as shown in the code snippet below: ```py def on_attribute(self, node): # ('value', 'attr', 'ctx') """Extract attribute.""" ctx = node.ctx.__class__ if ctx == ast.Store: msg = "attribute for storage: shouldn't be here!" self.raise_exception(node, exc=RuntimeError, msg=msg) sym = self.run(node.value) if ctx == ast.Del: return delattr(sym, node.at...