deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-2qph-v9p2-q2gv
Package: streampipes (PIP)
Severity: MODERATE (CVSS 3.7)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: < 0.95.0
Patched in: 0.95.0

Summary: Apache StreamPipes potentially allows creation of multiple identical accounts

Details:
Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache StreamPipes in user self-registration.
This allows an attacker to potentially request the creation of multiple accounts with the same email address until the email address is registered, creating many identical users and corrupting StreamPipe's user management.
This issue affects Apache StreamPipes: through 0.93.0.

Users are recommended to upgrade to version 0.95.0, which fixes the issue.
GitHub Security Advisory: GHSA-9gr7-gh74-qg9x
Package: streampipes (PIP)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.95.0
Patched in: 0.95.0

Summary: Apache StreamPipes has possibility of SSRF in pipeline element installation process

Details:
Server-Side Request Forgery (SSRF) vulnerability in Apache StreamPipes during installation process of pipeline elements.
Previously, StreamPipes allowed users to configure custom endpoints from which to install additional pipeline elements. 
These endpoints were not properly validated, allowing an attacker to get StreamPipes to send an HTTP GET request to an arbitrary address.

This issue affects Apache StreamPipes: through 0.93.0.

Users are recommended to upgrade to version 0.95.0, which fixes the issue.
GitHub Security Advisory: GHSA-6523-jf4r-c962
Package: streampipes (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: < 0.95.0
Patched in: 0.95.0

Summary: Apache StreamPipes has potential remote code execution (RCE) via file upload

Details:
Unrestricted Upload of File with dangerous type vulnerability in Apache StreamPipes.
Such a dangerous type might be an executable file that may lead to a remote code execution (RCE).
The unrestricted upload is only possible for authenticated and authorized users.

This issue affects Apache StreamPipes: through 0.93.0.

Users are recommended to upgrade to version 0.95.0, which fixes the issue.
GitHub Security Advisory: GHSA-qg33-x2c5-6p44
Package: langflow (PIP)
Severity: HIGH (CVSS 8.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-913: Improper Control of Dynamically-Managed Code Resources
Vulnerable versions: < 1.0.15
Patched in: 1.0.15

Summary: Langflow remote code execution vulnerability

Details:
Langflow allows remote code execution if untrusted users are able to reach the "POST /api/v1/custom_component" endpoint and provide a Python script.
GitHub Security Advisory: GHSA-fcr8-4r9f-r66m
Package: nbgrader (PIP)
Severity: HIGH (CVSS 0.0)
CWE: CWE-668: Exposure of Resource to Wrong Sphere, CWE-1021: Improper Restriction of Rendered UI Layers or Frames
Vulnerable versions: = 0.9.4
Patched in: 0.9.5

Summary: nbgrader's `frame-ancestors: self` grants all users access to formgrader

Details:
### Impact

Enabling frame-ancestors: 'self' grants any JupyterHub user the ability to extract formgrader content by sending malicious links to users with access to formgrader, at least when using the default JupyterHub configuration of `enable_subdomains = False`.

#1915 disables a protection which would allow user Alice to craft a page embedding formgrader in an IFrame. If Bob visits that page, his credentials will be sent and the formgrader page loaded. Because Alice's page is on the same Origin as the formgrader iframe, Javasript on Alice's page has _full access_ to the contents of the page served by formgrader using Bob's credentials.

### Workarounds

- Disable `frame-ancestors: self`, or
- enable per-user and per-service subdomains with `JupyterHub.enable_subdomains = True` (then even if embedding in an IFrame is allowed, the host page does not have access to the contents of the frame).

### References

JupyterHub documentation on why and when `frame-ancestors: self` is insecure, and why it was disabled by default: https://jupyterhub.readthedocs.io/en/stable/explanation/websecurity.html#:~:text=frame-ancestors
GitHub Security Advisory: GHSA-3wg7-r7q5-r2jf
Package: indico (PIP)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data, CWE-639: Authorization Bypass Through User-Controlled Key, CWE-862: Missing Authorization
Vulnerable versions: >= 3.2.9, < 3.3.3
Patched in: 3.3.3

Summary: Indico Insecure Access

Details:
A Broken Object Level Authorization (BOLA) vulnerability in Indico v3.2.9 allows attackers to access sensitive information via sending a crafted POST request to the component /api/principals.
GitHub Security Advisory: GHSA-7pq6-v88g-wf3w
Package: sentry (PIP)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 21.12.0, < 25.1.0
Patched in: 25.1.0

Summary: Sentry's improper authentication on SAML SSO process allows user impersonation

Details:
### Impact
A critical vulnerability was discovered in the SAML SSO implementation of Sentry. It was reported to us via our private bug bounty program.

The vulnerability allows an attacker to take over any user account by using a malicious SAML Identity Provider and another organization on the same Sentry instance. The victim email address must be known in order to exploit this vulnerability.

### Patches
- [Sentry SaaS](https://sentry.io): The fix was deployed on Jan 14, 2025.
- [Self-Hosted Sentry](https://github.com/getsentry/self-hosted): If only a single organization is allowed (`SENTRY_SINGLE_ORGANIZATION = True`), then no action is needed. Otherwise, users should upgrade to version 25.1.0 or higher.

### Workarounds
No known workarounds.

### References
- https://github.com/getsentry/sentry/pull/83407
GitHub Security Advisory: GHSA-qcgg-j2x8-h9g8
Package: Django (PIP)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 4.2, < 4.2.18
Patched in: 4.2.18

Summary: Django has a potential denial-of-service vulnerability in IPv6 validation

Details:
An issue was discovered in Django 5.1 before 5.1.5, 5.0 before 5.0.11, and 4.2 before 4.2.18. Lack of upper-bound limit enforcement in strings passed when performing IPv6 validation could lead to a potential denial-of-service attack. The undocumented and private functions `clean_ipv6_address` and `is_valid_ipv6_address` are vulnerable, as is the `django.forms.GenericIPAddressField` form field. (The django.db.models.GenericIPAddressField model field is not affected.)
GitHub Security Advisory: GHSA-qcgg-j2x8-h9g8
Package: Django (PIP)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.0, < 5.0.11
Patched in: 5.0.11

Summary: Django has a potential denial-of-service vulnerability in IPv6 validation

Details:
An issue was discovered in Django 5.1 before 5.1.5, 5.0 before 5.0.11, and 4.2 before 4.2.18. Lack of upper-bound limit enforcement in strings passed when performing IPv6 validation could lead to a potential denial-of-service attack. The undocumented and private functions `clean_ipv6_address` and `is_valid_ipv6_address` are vulnerable, as is the `django.forms.GenericIPAddressField` form field. (The django.db.models.GenericIPAddressField model field is not affected.)
GitHub Security Advisory: GHSA-qcgg-j2x8-h9g8
Package: Django (PIP)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.1, < 5.1.5
Patched in: 5.1.5

Summary: Django has a potential denial-of-service vulnerability in IPv6 validation

Details:
An issue was discovered in Django 5.1 before 5.1.5, 5.0 before 5.0.11, and 4.2 before 4.2.18. Lack of upper-bound limit enforcement in strings passed when performing IPv6 validation could lead to a potential denial-of-service attack. The undocumented and private functions `clean_ipv6_address` and `is_valid_ipv6_address` are vulnerable, as is the `django.forms.GenericIPAddressField` form field. (The django.db.models.GenericIPAddressField model field is not affected.)
GitHub Security Advisory: GHSA-m9g8-fxxm-xg86
Package: django (PIP)
Severity: HIGH (CVSS 9.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 4.2, < 4.2.17
Patched in: 4.2.17

Summary: Django SQL injection in HasKey(lhs, rhs) on Oracle

Details:
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. Direct usage of the django.db.models.fields.json.HasKey lookup, when an Oracle database is used, is subject to SQL injection if untrusted data is used as an lhs value. (Applications that use the jsonfield.has_key lookup via __ are unaffected.)
GitHub Security Advisory: GHSA-m9g8-fxxm-xg86
Package: django (PIP)
Severity: HIGH (CVSS 9.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 5.0, < 5.0.10
Patched in: 5.0.10

Summary: Django SQL injection in HasKey(lhs, rhs) on Oracle

Details:
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. Direct usage of the django.db.models.fields.json.HasKey lookup, when an Oracle database is used, is subject to SQL injection if untrusted data is used as an lhs value. (Applications that use the jsonfield.has_key lookup via __ are unaffected.)
GitHub Security Advisory: GHSA-m9g8-fxxm-xg86
Package: django (PIP)
Severity: HIGH (CVSS 9.8)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 5.1, < 5.1.4
Patched in: 5.1.4

Summary: Django SQL injection in HasKey(lhs, rhs) on Oracle

Details:
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. Direct usage of the django.db.models.fields.json.HasKey lookup, when an Oracle database is used, is subject to SQL injection if untrusted data is used as an lhs value. (Applications that use the jsonfield.has_key lookup via __ are unaffected.)
GitHub Security Advisory: GHSA-cpv4-ggrr-7j9v
Package: rasa (PIP)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 3.6.21
Patched in: 3.6.21

Summary: Rasa Allows Remote Code Execution via Remote Model Loading

Details:
## Vulnerability
A vulnerability has been identified in Rasa Pro and Rasa Open Source that enables an attacker who has the ability to load a maliciously crafted model remotely into a Rasa instance to achieve Remote Code Execution.

The prerequisites for this are:
- The HTTP API must be enabled on the Rasa instance eg with `--enable-api`. This is not the default configuration.
- For unauthenticated RCE to be exploitable, the user must not have configured any authentication or other security controls recommended in our documentation.
- For authenticated RCE, the attacker must posses a valid authentication token or JWT to interact with the Rasa API.

## Fix
We encourage you to upgrade to a version of Rasa that includes a fix. These are:

- Rasa Pro 3.8.18, 3.9.16, 3.10.12
- Rasa Open Source 3.6.21

Once you have upgraded your Rasa Pro or Open Source installation, you will need to retrain your model using the fixed version of Rasa Pro or Open Source. If you have a custom component that inherits from one of the components listed below and modified the persist or load method, make sure to update your code. Please contact us in case you encounter any problems.

Affected components:

- `CountVectorFeaturizer`
- `LexicalSyntacticFeaturizer`
- `LogisticRegressionClassifier`
- `SklearnIntentClassifier`
- `DIETClassifier`
- `CRFEntityExtractor`
- `TrackerFeaturizer`
- `TEDPolicy`
- `UnexpectedIntentTEDPolicy`

If you are unable to upgrade immediately, please follow our mitigation advice below.

## Mitigation Advice

- The unauthenticated RCE can be mitigated by ensuring that you enable authentication for the Rasa HTTP API if this is enabled. This means that in addition to passing `--enable-api` to Rasa, you should also pass an authentication configuration as described in our documentation [here](https://rasa.com/docs/rasa-pro/production/rest-api/#enabling-the-rest-api). 

- The authenticated RCE can be mitigated by:
    - Ensuring that you only load models from trusted sources such as your own CI pipelines. You can check file hashes for model archives to confirm that a model has not been tampered with between training and use.
    - Confirming that you have sufficient access controls and utilize the principle of least privilege to control who in your organization has the ability to interact with the Rasa API even with authentication enabled.

## Future Releases
As an additional security step, a future release of Rasa Pro will remove the ability to enable the API without any authentication method enabled.

## Credit
Rasa would like to thank Julian Scheid from Deutsche Telekom Security GmbH for responsible disclosure of this vulnerability.
GitHub Security Advisory: GHSA-cpv4-ggrr-7j9v
Package: rasa-pro (PIP)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: < 3.8.18
Patched in: 3.8.18

Summary: Rasa Allows Remote Code Execution via Remote Model Loading

Details:
## Vulnerability
A vulnerability has been identified in Rasa Pro and Rasa Open Source that enables an attacker who has the ability to load a maliciously crafted model remotely into a Rasa instance to achieve Remote Code Execution.

The prerequisites for this are:
- The HTTP API must be enabled on the Rasa instance eg with `--enable-api`. This is not the default configuration.
- For unauthenticated RCE to be exploitable, the user must not have configured any authentication or other security controls recommended in our documentation.
- For authenticated RCE, the attacker must posses a valid authentication token or JWT to interact with the Rasa API.

## Fix
We encourage you to upgrade to a version of Rasa that includes a fix. These are:

- Rasa Pro 3.8.18, 3.9.16, 3.10.12
- Rasa Open Source 3.6.21

Once you have upgraded your Rasa Pro or Open Source installation, you will need to retrain your model using the fixed version of Rasa Pro or Open Source. If you have a custom component that inherits from one of the components listed below and modified the persist or load method, make sure to update your code. Please contact us in case you encounter any problems.

Affected components:

- `CountVectorFeaturizer`
- `LexicalSyntacticFeaturizer`
- `LogisticRegressionClassifier`
- `SklearnIntentClassifier`
- `DIETClassifier`
- `CRFEntityExtractor`
- `TrackerFeaturizer`
- `TEDPolicy`
- `UnexpectedIntentTEDPolicy`

If you are unable to upgrade immediately, please follow our mitigation advice below.

## Mitigation Advice

- The unauthenticated RCE can be mitigated by ensuring that you enable authentication for the Rasa HTTP API if this is enabled. This means that in addition to passing `--enable-api` to Rasa, you should also pass an authentication configuration as described in our documentation [here](https://rasa.com/docs/rasa-pro/production/rest-api/#enabling-the-rest-api). 

- The authenticated RCE can be mitigated by:
    - Ensuring that you only load models from trusted sources such as your own CI pipelines. You can check file hashes for model archives to confirm that a model has not been tampered with between training and use.
    - Confirming that you have sufficient access controls and utilize the principle of least privilege to control who in your organization has the ability to interact with the Rasa API even with authentication enabled.

## Future Releases
As an additional security step, a future release of Rasa Pro will remove the ability to enable the API without any authentication method enabled.

## Credit
Rasa would like to thank Julian Scheid from Deutsche Telekom Security GmbH for responsible disclosure of this vulnerability.
GitHub Security Advisory: GHSA-cpv4-ggrr-7j9v
Package: rasa-pro (PIP)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.9.0, < 3.9.16
Patched in: 3.9.16

Summary: Rasa Allows Remote Code Execution via Remote Model Loading

Details:
## Vulnerability
A vulnerability has been identified in Rasa Pro and Rasa Open Source that enables an attacker who has the ability to load a maliciously crafted model remotely into a Rasa instance to achieve Remote Code Execution.

The prerequisites for this are:
- The HTTP API must be enabled on the Rasa instance eg with `--enable-api`. This is not the default configuration.
- For unauthenticated RCE to be exploitable, the user must not have configured any authentication or other security controls recommended in our documentation.
- For authenticated RCE, the attacker must posses a valid authentication token or JWT to interact with the Rasa API.

## Fix
We encourage you to upgrade to a version of Rasa that includes a fix. These are:

- Rasa Pro 3.8.18, 3.9.16, 3.10.12
- Rasa Open Source 3.6.21

Once you have upgraded your Rasa Pro or Open Source installation, you will need to retrain your model using the fixed version of Rasa Pro or Open Source. If you have a custom component that inherits from one of the components listed below and modified the persist or load method, make sure to update your code. Please contact us in case you encounter any problems.

Affected components:

- `CountVectorFeaturizer`
- `LexicalSyntacticFeaturizer`
- `LogisticRegressionClassifier`
- `SklearnIntentClassifier`
- `DIETClassifier`
- `CRFEntityExtractor`
- `TrackerFeaturizer`
- `TEDPolicy`
- `UnexpectedIntentTEDPolicy`

If you are unable to upgrade immediately, please follow our mitigation advice below.

## Mitigation Advice

- The unauthenticated RCE can be mitigated by ensuring that you enable authentication for the Rasa HTTP API if this is enabled. This means that in addition to passing `--enable-api` to Rasa, you should also pass an authentication configuration as described in our documentation [here](https://rasa.com/docs/rasa-pro/production/rest-api/#enabling-the-rest-api). 

- The authenticated RCE can be mitigated by:
    - Ensuring that you only load models from trusted sources such as your own CI pipelines. You can check file hashes for model archives to confirm that a model has not been tampered with between training and use.
    - Confirming that you have sufficient access controls and utilize the principle of least privilege to control who in your organization has the ability to interact with the Rasa API even with authentication enabled.

## Future Releases
As an additional security step, a future release of Rasa Pro will remove the ability to enable the API without any authentication method enabled.

## Credit
Rasa would like to thank Julian Scheid from Deutsche Telekom Security GmbH for responsible disclosure of this vulnerability.
GitHub Security Advisory: GHSA-cpv4-ggrr-7j9v
Package: rasa-pro (PIP)
Severity: CRITICAL (CVSS 9.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-502: Deserialization of Untrusted Data
Vulnerable versions: >= 3.10.0, < 3.10.12
Patched in: 3.10.12

Summary: Rasa Allows Remote Code Execution via Remote Model Loading

Details:
## Vulnerability
A vulnerability has been identified in Rasa Pro and Rasa Open Source that enables an attacker who has the ability to load a maliciously crafted model remotely into a Rasa instance to achieve Remote Code Execution.

The prerequisites for this are:
- The HTTP API must be enabled on the Rasa instance eg with `--enable-api`. This is not the default configuration.
- For unauthenticated RCE to be exploitable, the user must not have configured any authentication or other security controls recommended in our documentation.
- For authenticated RCE, the attacker must posses a valid authentication token or JWT to interact with the Rasa API.

## Fix
We encourage you to upgrade to a version of Rasa that includes a fix. These are:

- Rasa Pro 3.8.18, 3.9.16, 3.10.12
- Rasa Open Source 3.6.21

Once you have upgraded your Rasa Pro or Open Source installation, you will need to retrain your model using the fixed version of Rasa Pro or Open Source. If you have a custom component that inherits from one of the components listed below and modified the persist or load method, make sure to update your code. Please contact us in case you encounter any problems.

Affected components:

- `CountVectorFeaturizer`
- `LexicalSyntacticFeaturizer`
- `LogisticRegressionClassifier`
- `SklearnIntentClassifier`
- `DIETClassifier`
- `CRFEntityExtractor`
- `TrackerFeaturizer`
- `TEDPolicy`
- `UnexpectedIntentTEDPolicy`

If you are unable to upgrade immediately, please follow our mitigation advice below.

## Mitigation Advice

- The unauthenticated RCE can be mitigated by ensuring that you enable authentication for the Rasa HTTP API if this is enabled. This means that in addition to passing `--enable-api` to Rasa, you should also pass an authentication configuration as described in our documentation [here](https://rasa.com/docs/rasa-pro/production/rest-api/#enabling-the-rest-api). 

- The authenticated RCE can be mitigated by:
    - Ensuring that you only load models from trusted sources such as your own CI pipelines. You can check file hashes for model archives to confirm that a model has not been tampered with between training and use.
    - Confirming that you have sufficient access controls and utilize the principle of least privilege to control who in your organization has the ability to interact with the Rasa API even with authentication enabled.

## Future Releases
As an additional security step, a future release of Rasa Pro will remove the ability to enable the API without any authentication method enabled.

## Credit
Rasa would like to thank Julian Scheid from Deutsche Telekom Security GmbH for responsible disclosure of this vulnerability.
GitHub Security Advisory: GHSA-8498-2h75-472j
Package: django (PIP)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 4.2, < 4.2.17
Patched in: 4.2.17

Summary: Django denial-of-service in django.utils.html.strip_tags()

Details:
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The strip_tags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities.
GitHub Security Advisory: GHSA-8498-2h75-472j
Package: django (PIP)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.0, < 5.0.10
Patched in: 5.0.10

Summary: Django denial-of-service in django.utils.html.strip_tags()

Details:
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The strip_tags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities.
GitHub Security Advisory: GHSA-8498-2h75-472j
Package: django (PIP)
Severity: MODERATE (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 5.1, < 5.1.4
Patched in: 5.1.4

Summary: Django denial-of-service in django.utils.html.strip_tags()

Details:
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. The strip_tags() method and striptags template filter are subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities.