### Summary

All Filament features that interact with storage use the `default_filesystem_disk` config option. This allows the user to easily swap their storage driver to something production-ready like `s3` when deploying their app, without having to touch multiple configuration options and potentially forgetting about some.

The default disk is set to `public` when you first install Filament, since this allows users to quickly get started developing with a functional disk that allows features such as file upload previews locally without the need to set up an S3 disk with temporary URL support.

However, some features of Filament such as exports also rely on storage, and the files that are stored contain data that should often not be public. This is not an issue for the many deployed applications, since many use a secure default disk such as S3 in production. However, [CWE-1188](https://cwe.mitre.org/data/definitions/1188.html) suggests that having the `public` disk as the default disk in Filament is a security vulnerability itself:

> Developers often choose default values that leave the product as open and easy to use as possible out-of-the-box, under the assumption that the administrator can (or should) change the default value. However, this ease-of-use comes at a cost when the default is insecure and the administrator does not change it.

As such, we have implemented a measure to protect users whereby if the `public` disk is set as the default disk, the exports feature will automatically swap it out for the `local` disk, if that exists. Users who set the default disk to `local` or `s3` already are not affected. If a user wants to continue to use the `public` disk for exports, they can by [setting the export disk](https://filamentphp.com/docs/3.x/actions/prebuilt-actions/export#customizing-the-storage-disk) deliberately.

### Details

**Product:** filament/actions
**Version:** >=3.2
**CWE-ID:**[CWE-1188](https://cwe.mitre.org/data/definitions/1188.html): Initialization of a Resource with an Insecure Default
**Description:** The default configuration saves export files to a public disk, allowing unauthorized users to download exported data.
**Impact:** Reading export files without access control
**Vulnerable component:**
https://github.com/filamentphp/filament/blob/3.x/packages/actions/src/Exports/Exporter.php#L144-L153
**Exploitation conditions:** Unauthorized user
**Researcher:** Vladislav Gladky (Positive Technologies)

**Summary**

All Filament features that interact with storage use the default_filesystem_disk config option. This allows the user to easily swap their storage driver to something production-ready like s3 when deploying their app, without having to touch multiple configuration options and potentially forgetting about some.

The default disk is set to public when you first install Filament, since this allows users to quickly get started developing with a functional disk that allows features such as file upload previews locally without the need to set up an S3 disk with temporary URL support.

However, some features of Filament such as exports also rely on storage, and the files that are stored contain data that should often not be public. This is not an issue for the many deployed applications, since many use a secure default disk such as S3 in production. However, CWE-1188 suggests that having the public disk as the default disk in Filament is a security vulnerability itself:

> Developers often choose default values that leave the product as open and easy to use as possible out-of-the-box, under the assumption that the administrator can (or should) change the default value. However, this ease-of-use comes at a cost when the default is insecure and the administrator does not change it.

As such, we have implemented a measure to protect users whereby if the public disk is set as the default disk, the exports feature will automatically swap it out for the local disk, if that exists. Users who set the default disk to local or s3 already are not affected. If a user wants to continue to use the public disk for exports, they can by setting the export disk deliberately.

**Details**

**Product:** filament/actions  
**Version:** >=3.2  
**CWE-ID:**CWE-1188: Initialization of a Resource with an Insecure Default  
**Description:** The default configuration saves export files to a public disk, allowing unauthorized users to download exported data.  
**Impact:** Reading export files without access control  
**Vulnerable component:**  
https://github.com/filamentphp/filament/blob/3.x/packages/actions/src/Exports/Exporter.php#L144-L153  
**Exploitation conditions:** Unauthorized user  
**Researcher:** Vladislav Gladky (Positive Technologies)

**References**

*   GHSA-4hxw-gc2q-f6f3
*   filamentphp/filament@19f5347
*   https://github.com/filamentphp/filament/blob/3.x/packages/actions/src/Exports/Exporter.php#L144-L153

GHSA-4hxw-gc2q-f6f3: Filament has exported files stored in default (`public`) filesystem if not reconfigured

Red Hat Security Advisory 2024-8690-03 - Red Hat OpenShift Container Platform release 4.13.53 is now available with updates to packages and images that fix several bugs and add enhancements. Issues addressed include denial of service and traversal vulnerabilities.

The following advisory data is extracted from:

https://security.access.redhat.com/data/csaf/v2/advisories/2024/rhsa-2024_8690.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: OpenShift Container Platform 4.13.53 packages and  security update  
Advisory ID:        RHSA-2024:8690-03  
Product:            Red Hat OpenShift Enterprise  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:8690  
Issue date:         2024-11-07  
Revision:           03  
CVE Names:          CVE-2024-9341  
====================================================================

Summary: 

Red Hat OpenShift Container Platform release 4.13.53 is now available with updates to packages and images that fix several bugs and add enhancements.

This release includes a security update for Red Hat OpenShift Container Platform 4.13.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.

This advisory contains the container images for Red Hat OpenShift Container Platform 4.13.53. See the following advisory for the RPM packages for this release:

https://access.redhat.com/errata/RHSA-2024:8688

Security Fix(es):

* buildah: Buildah allows arbitrary directory mount (CVE-2024-9675)  
* encoding/gob: golang: Calling Decoder.Decode on a message which contains  
deeply nested structures can cause a panic due to stack exhaustion  
(CVE-2024-34156)  
* Podman: Buildah: cri-o: FIPS Crypto-Policy Directory Mounting Issue in  
containers/common Go Library (CVE-2024-9341)  
* Podman: Buildah: CRI-O: symlink traversal vulnerability in the  
containers/storage library can cause Denial of Service (DoS)  
(CVE-2024-9676)  
* go/parser: golang: Calling any of the Parse functions containing deeply  
nested literals can cause a panic/stack exhaustion (CVE-2024-34155)  
* go/build/constraint: golang: Calling Parse on a \"// +build\" build tag  
line with deeply nested expressions can cause a panic due to stack  
exhaustion (CVE-2024-34158)

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section. 

All OpenShift Container Platform 4.13 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.openshift.com/container-platform/4.13/updating/updating-cluster-cli.html

Solution:

https://docs.openshift.com/container-platform/4.13/release_notes/ocp-4-13-release-notes.html

CVEs:

CVE-2024-9341

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2310527  
https://bugzilla.redhat.com/show_bug.cgi?id=2310528  
https://bugzilla.redhat.com/show_bug.cgi?id=2310529  
https://bugzilla.redhat.com/show_bug.cgi?id=2315691  
https://bugzilla.redhat.com/show_bug.cgi?id=2317458  
https://bugzilla.redhat.com/show_bug.cgi?id=2317467

Red Hat Security Advisory 2024-8690-03

The bulk message sending feature in Moodle's Feedback module's non-respondents report had an incorrect CSRF token check, leading to a CSRF vulnerability.

**Exploitability Metrics**

Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.

Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.

Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.

Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

**Vulnerable System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

**Subsequent System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

GHSA-x87r-37q5-mmr8: Moodle has CSRF risk in Feedback non-respondents report

A flaw was found in moodle. A local file may include risks when restoring block backups.

GHSA-qrqv-26gf-xgwh: Moodle LFI vulnerability when restoring malformed block backups

To address a cache poisoning risk in Moodle, additional validation for local storage was required.

GHSA-2r9m-wg35-rfvc: Moodle vulnerable to cache poisoning via injection into storage

A flaw was found in pdfTeX. Insufficient sanitizing in the TeX notation filter resulted in an arbitrary file read risk on sites where pdfTeX is available, such as those with TeX Live installed.

GHSA-vjmm-r9gg-425m: Moodle has arbitrary file read risk through pdfTeX

A flaw was found in Moodle. Additional restrictions are required to avoid a remote code execution risk in calculated question types. Note: This requires the capability to add/update questions.

GHSA-v6f4-v8h8-3c87: Moodle Remote Code Execution vulnerability

A SQL injection risk flaw was found in the XMLDB editor tool available to site administrators.

GHSA-mx26-62xm-2p83: Moodle vulnerable to site administration SQL injection via XMLDB editor

A vulnerability was found in Moodle. Insufficient capability checks made it possible to delete badges that a user does not have permission to access.

GHSA-wwjf-gwrv-wh45: Moodle's IDOR in badges allows deletion of arbitrary badges

A flaw was found in Feedback. Bulk messaging in the activity's non-respondents report did not verify message recipients belonging to the set of users returned by the report.

Tag

#vulnerability