ghsa

BerriAI/litellm is vulnerable to Server-Side Template Injection (SSTI) via the `/completions` endpoint. The vulnerability arises from the `hf_chat_template` method processing the `chat_template` parameter from the `tokenizer_config.json` file through the Jinja template engine without proper sanitization. Attackers can exploit this by crafting malicious `tokenizer_config.json` files that execute arbitrary code on the server.

### Impact Parameters of UI extensions are always interpreted as Velocity code and executed with programming rights. Any user with edit right on any document like the user's own profile can create UI extensions. This allows remote code execution and thereby impacts the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, edit your user profile with the object editor and add a UIExtension object with the following values: ``` Extension Point ID: org.xwiki.platform.panels.Applications Extension ID: platform.panels.myFakeApplication Extension parameters:  label=I got programming right: $services.security.authorization.hasAccess('programming') target=Main.WebHome targetQueryString= icon=icon:bomb Extension Scope: "Current User". ``` Save the document and open any document. If an application entry with the text "I got programming right: true" is displayed, the attack succeeded, if the code in "label" is displayed literally, the XWiki installation isn'...

### Impact The HTML escaping of escaping tool that is used in XWiki doesn't escape `{`, which, when used in certain places, allows XWiki syntax injection and thereby remote code execution. To reproduce in an XWiki installation, open `<xwiki-host>/xwiki/bin/view/Panels/PanelLayoutUpdate?place=%7B%7B%2Fhtml%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bvelocity%7D%7D%23evaluate(%24request.eval)%7B%7B%2Fvelocity%7D%7D%7B%7B%2Fasync%7D%7D&eval=Hello%20from%20URL%20Parameter!%20I%20got%20programming%3A%20%24services.security.authorization.hasAccess(%27programming%27)` where `<xwiki-host>` is the URL of your XWiki installation. If this displays `You are not admin on this place Hello from URL Parameter! I got programming: true`, the installation is vulnerable. ### Patches The vulnerability has been fixed on XWiki 14.10.19, 15.5.5, and 15.9 RC1. ### Workarounds Apart from upgrading, there is no generic workaround. However, replacing `$escapetool.html` by `$escapetool.xml` in XWiki documents f...

### Impact When invoking a capability with a chain depth of 2, i.e., it is delegated directly from the root capability, the `expires` property is not properly checked against the current date or other `date` param. This can allow invocations outside of the original intended time period. A zcap still cannot be invoked without being able to use the associated private key material. ### Patches `@digitalbazaar/zcap` v9.0.1 fixes expiration checking. ### Workarounds A zcap could be revoked at any time. ### References https://github.com/digitalbazaar/zcap/pull/82

### Impact At the end of the request handling, it will encrypt all data in the session with a secret key and attach the ciphertext as a cookie value with the defined cookie name. After that, the session on the server side is destroyed. When an encrypted cookie with matching session name is provided with subsequent requests, it will decrypt the ciphertext to get the data. The plugin then creates a new session with the data in the ciphertext. Thus theoretically the web instance is still accessing the data from a server-side session, but technically that session is generated solely from a user provided cookie (which is assumed to be non-craftable because it is encrypted with a secret key not known to the user). The issue exists in the session removal process. In the delete function of the code, when the session is deleted, it is marked for deletion. However, if an attacker could gain access to the cookie, they could keep using it forever. ### Patches Fixed in 56d66642ecc633cff06069276...

### Impact _What kind of vulnerability is it? Who is impacted?_ Storage credentials are written to the console. ### Patches _Has the problem been patched?_ Yes, see #3589 _What versions should users upgrade to?_ - Any version after or including commit 1d6f852cd6534f4bea978cbdc85c583803d79f77 - No release has been created yet. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ - Be aware that `kopia repo status --json` will write the credentials to the output without scrubbing them. - Avoid executing `kopia repo status` with the `--json` flag in an insecure environment where. - Avoid logging the output of the `kopia repo status --json` command.

### Impact When the realtime editor is installed in XWiki, it allows arbitrary remote code execution with the interaction of an admin user with programming right. More precisely, by getting an admin user to either visit a crafted URL or to view an image with this URL that could be in a comment, the attacker can get the admin to execute arbitrary XWiki syntax including scripting macros with Groovy or Python code. This compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on an XWiki installation, as an admin, click on `<xwiki-host>/xwiki/bin/get/RTFrontend/ConvertHTML?wiki=xwiki&space=Main&page=WebHome&text=%7B%7Bvelocity%7D%7D%24logtool.error%28%22Hello%20from%20Velocity%20%21%22%29%7B%7B%2Fvelocity%7D%7D`. If the error "Hello from Velocity!" gets logged then the installation is vulnerable. ### Patches This vulnerability has been patched in XWiki 14.10.19, 15.5.4 and 15.9. ### Workarounds Update `RTFrontend.ConvertHTML` following t...

### Impact Any user who can edit any page like their profile can create a custom skin with a template override that is executed with programming right, thus allowing remote code execution. To reproduce, as a user without edit, script or admin right, add an object of class `XWiki.XWikiSkins` to your profile. Name it whatever you want and set the Base Skin to `flamingo`. Add an object of class `XWikiSkinFileOverrideClass` and set the path to `macros.vm` and the content to: ``` #macro(mediumUserAvatar $username) #resizedUserAvatar($username 50) $services.logging.getLogger('Skin').error("I got programming: $services.security.authorization.hasAccess('programming')") #end ``` Back to your profile, click `Test this skin`. Force a refresh, just in case. If the error "Skin - I got programming: true" gets logged, the installation is vulnerable. ### Patches This has been patched in XWiki 14.10.19, 15.5.4 and 15.10RC1. ### Workarounds We're not aware of any workaround except upgrading. ##...

### Impact By creating a document with a special crafted documented reference and an `XWiki.SchedulerJobClass` XObject, it is possible to execute arbitrary code on the server whenever an admin visits the scheduler page or the scheduler page is referenced, e.g., via an image in a comment on a page in the wiki. To reproduce on an XWiki installation, click on this link to create a new document : `<xwiki-host>/xwiki/bin/view/%22%3E%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%20context%3D%22request/parameters%22%7D%7D%7B%7Bvelocity%7D%7D%23evaluate%28%24request/eval%29/`. Then, add to this document an object of type `XWiki.SchedulerJobClass`. Finally, as an admin, go to `<xwiki-host>/xwiki/bin/view/Scheduler/?eval=$services.logging.getLogger(%22attacker%22).error(%22Hello%20from%20URL%20Parameter!%20I%20got%20programming:%20$services.security.authorization.hasAccess(%27programming%27)%22)`. If the logs contain `ERROR attacker - Hello from URL Parameter! I got programming: true`, the installation ...

### Impact It is possible to schedule/trigger/unschedule existing jobs by having an admin visit the Job Scheduler page through a predictable URL, for example by embedding such an URL in any content as an image. To reproduce in an XWiki installation, open `<xwiki-host>:/xwiki/bin/view/Scheduler/?do=trigger&which=Scheduler.NotificationEmailDailySender` as a user with admin rights. If there is no error message that indicates the CSRF token is invalid, the installation is vulnerable. ### Patches The vulnerability has been fixed on XWiki 14.10.19, 15.5.5, and 15.9. ### Workarounds Modify the Scheduler.WebHome page following this [patch](https://github.com/xwiki/xwiki-platform/commit/f16ca4ef1513f84ce2e685d4a05d689bd3a2ab4c#diff-1e2995eacccbbbdcc4987ff64f46ac74837d166cf9e92920b4a4f8af0f10bd47). ### References - https://jira.xwiki.org/browse/XWIKI-20851 - https://github.com/xwiki/xwiki-platform/commit/f16ca4ef1513f84ce2e685d4a05d689bd3a2ab4c