Shirabe0X05

When an Agent composes redirect and shared cache interceptors, a cached response revalidated with a conditional request may be incorrectly validated by a 304 Not Modified response from a different origin. This occurs because the redirect handler removes origin-bound credential headers but fails to remove cache-generated `If-None-Match` or `If-Modified-Since` validators. Consequently, the redirect destination receives the original origin's validator, and the system treats the 304 response as a successful revalidation. This can lead to a shared cache serving an authenticated response, such as one protected by an `Authorization` header, to an unauthenticated caller.

The redirect interceptor fails to strip sensitive headers—including `Authorization`, `Cookie`, `Proxy-Authorization`, and `Host`—when a request is redirected to a different origin if the request headers are provided as an array of name and value tuples. In this scenario, the redirect handler misinterprets the tuples as a flat list, preventing the header names from matching and allowing sensitive headers to remain. If a header-normalizing interceptor, such as cache or deduplicate, is composed outside the redirect interceptor, these retained headers are serialized onto the cross-origin request, potentially disclosing origin-bound credentials to an unrelated destination.

An authorization flaw exists in the `login.invite` task. This issue allows page authors to obtain super user accounts by defining an invitation form that grants super access within the page frontmatter. An unauthenticated attacker can then submit this form and register the invited address to gain full control of the site.

An authorization bypass exists in the generic '/api/v1/flex-objects/pages' API endpoint. The issue occurs because the system only verifies directory-level `admin.pages` permissions and fails to enforce page-level permission rules or the Pages API's `api.pages.read/write` permissions. Consequently, authenticated non-super users possessing `api.access` and either `admin.pages` or `admin.configuration.pages` permissions can read page source and frontmatter, modify content, or delete pages for which they lack authorization.

An improper access control issue exists in the `dynamicFlexField()` function within `FlexDirectory`. This allows page authors to execute arbitrary Flex object methods by using `flex-*@` directives in the page frontmatter. If a user with page edit permissions opens the affected page, directives that call `setStorageKey()` and `delete()` are executed within their session, potentially leading to the deletion of protected pages that neither the author nor the editor should be able to remove.