Seungbin Yang

Broken access control exists in the frontend management update flow. The system verifies a different event than the one actually being modified, allowing a user with frontend event management access to modify events belonging to other organizers.

Broken access control exists in the frontend edit, update, and activate actions. The extension resolves the targeted club record from a user-supplied request argument but fails to perform an ownership check. Consequently, an unauthenticated visitor who knows the UID of a club record can send a direct request to the update or activate action to overwrite the record or publish one that is awaiting approval without owning it.

The company self-service editing feature fails to perform server-side ownership verification during write operations. While the frontend uses a visibility flag to hide the edit form from unauthorized users, the server does not validate if the visitor owns the company record being modified. An attacker who obtains a company record identifier from the public directory can submit a modified update request to overwrite the record data.

The frontend topic editing flow fails to perform server-side verification to ensure the requesting visitor owns the topic being modified. An attacker can obtain a topic identifier from the public forum and submit a modified update request to overwrite the content of that topic. This issue requires no privileged access or non-default configuration.

The frontend management plugin contains a broken access control issue. The system attributes a newly created event to the submitting user's organizer record only if the request does not specify an organizer. Because the permission check only verifies that the submitting user possesses any organizer role, a user with frontend event management access can create an event and attribute it to a different organizer.

The frontend detail-view document lookup fails to apply the `siteHash` filter for the current site and the frontend user access filter. This differs from the regular search path, allowing a visitor who possesses or guesses a valid Solr document id to retrieve documents without the standard access restrictions.

The extension allows a request-provided `additionalFilters` parameter to register a named `siteHash` filter before the system's own `siteHash` filter is applied. Because the query builder does not overwrite an already-registered named filter, a visitor can read public documents belonging to another site in a shared Solr core serving multiple TYPO3 sites. This issue also affects the suggest top-results path when suggest is enabled.

The extension fails to restrict which frontend usergroups a logged-in user may assign to their own account when the profile edit plugin uses its default field configuration. This flaw allows for self-service privilege escalation into arbitrary frontend groups.

The extension does not require a dedicated admin confirmation token when processing admin-approval requests. This allows a regular user to self-approve a pending account by using a user confirmation hash, which can be obtained by any visitor through the public resend-confirmation action.

An authenticated backend user with access to the Mask module can perform path traversal, a technique used to access files and directories that are restricted from the user. The extension fails to validate a client-supplied template element key used to build file paths for saving and deleting Mask template files. By supplying a key containing path traversal sequences, an attacker can create or delete .html files outside the configured template directory.

Broken access control exists in the extension where the HMAC (Hash-based Message Authentication Code, a mechanism for verifying data integrity and authenticity) of a frontend employee edit link is validated only when rendering the edit form, but not when persisting the changes. An unauthenticated visitor who knows the UID of a visible employee record can send a direct POST request to the update action to overwrite that record without a valid edit link or ownership verification.

The OOXML parsing of the file indexer fails to disable external entity resolution. This allows an attacker to use a specially crafted xlsx or pptx document placed in an indexed directory to trigger XML External Entity (XXE) injection—a process where an application processes external entities within an XML document. This can result in the reading of local files or the execution of outbound HTTP requests, with the retrieved data being written to the search index.

The `additional tables` configuration of the page and tt content indexers allows the use of arbitrary table and field names. A backend user with permissions to edit indexer configurations can exploit this to copy sensitive data from internal tables into the search index.

The file indexer fails to normalize the configured directory path. This allows a backend user with permissions to edit indexer configurations to index documents from arbitrary locations on the server file system by using path traversal sequences, which are characters used to navigate through the directory hierarchy to access files outside the intended folder.

The create and edit flows fail to restrict submitted user properties and do not enforce access control on frontend user group assignments. This allows an attacker to assign an arbitrary frontend user group to a newly registered or edited account, leading to unauthorized access to content and functionality reserved for privileged frontend user groups.