The password reset function in ILIAS 7.0_beta1 through 7.20 and 8.0_beta1 through 8.1 allows remote attackers to take over the account.

CVE-2023-36487

The web interface of Gira Giersiepen Gira KNX/IP-Router 3.1.3683.0 and 3.3.8.0 allows a remote attacker to read sensitive files via directory-traversal sequences in the URL.

1.  Your Expert in Penetration Testing
2.  Pentest blog

**Research and Responsibility**

SySS GmbH deals with security issues in a responsible way. In the form of a security advisory we report security vulnerabilities which are not in products of our customers and which are not excluded from public disclosure due to contractual agreements with vendors.

The security advisory contains detailed information about the found vulnerability that allows the vendor to reproduce and further investigate the reported security issue. Vulnerabilities will be disclosed to the public if a solution was published by the vendor or 45 days after the initial report by the SySS GmbH, regardless of the vulnerability status, for example if there is a patch or workaround from the affected vendor. In well-founded exceptional cases, this standard procedure may not be followed and an alternative, adjusted publication schedule will be negotiated with the vendor. 

The goal of our Responsible Disclosure Policy is, to weigh up the need of the public to know of security vulnerabilities against the vendor’s time to remedy all security issues effectively. The final publication schedule will be based on the best interests of the community overall, considering both positions. Before the responsible disclosure of a security vulnerability, the SySS GmbH allows vendors the opportunity to analyze reported security issues, to develop effective countermeasures, and to test them thoroughly.

DO NOT HESITATE TO GET IN TOUCH +49 (0)7071 - 40 78 56-0 or anfrage@syss.de | OUTSIDE REGULAR OFFICE Hours CALL +49 (0)7071 - 40 78 56-99

As a framework contract customer please dial the provided on-call service number

DO NOT HESITATE TO GET IN TOUCH +49 (0)7071 - 40 78 56-0 or anfrage@syss.de

OUTSIDE REGULAR OFFICE Hours CALL +49 (0)7071 - 40 78 56-99

As a framework contract customer please dial the provided on-call service number

GET IN TOUCH

+49 (0)7071 - 40 78 56-0 or anfrage@syss.de

OUTSIDE REGULAR OFFICE Hours

+49 (0)7071 - 40 78 56-99

As a framework contract customer please dial the provided on-call service number

CVE-2023-33277: Responsible Disclosure Policy

An issue was discovered in the GoogleAnalyticsMetrics extension for MediaWiki through 1.39.3. The googleanalyticstrackurl parser function does not properly escape JavaScript in the onclick handler and does not prevent use of javascript: URLs.

**

GoogleAnalyticsMetrics extension - XSS

Closed, ResolvedPublicSecurity



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

#googleanalyticstrackurl parser function in extension does not properly escape js in onclick handler and does not prevent using javascript urls.

Additionally it does not register external links in the parser (important for antispam).

Risk Rating

Medium

Author Affiliation

Wikimedia Communities

**Event Timeline**

Comment Actions

			return '<strong class="error">' .
				wfMessage( 'googleanalyticsmetrics-invalid-url' )->text() .
				'</strong>';

Doesn’t this need to be \->parse() or \->escaped() to prevent HTML injection from the googleanalyticsmetrics-invalid-url message?

Comment Actions

> 			return '<strong class="error">' .
> 				wfMessage( 'googleanalyticsmetrics-invalid-url' )->text() .
> 				'</strong>';
> 
> Doesn’t this need to be \->parse() or \->escaped() to prevent HTML injection from the googleanalyticsmetrics-invalid-url message?

No, because parser functions (unlike tag extensions) return wikitext if you return a string from them. So the return value is interpreted as being wikitext and does all normal wikitext escaping.

Comment Actions

> @Mstyles Can this be added to next extension security supplement?

Yes, added: T333626. Also going to just make this public now.

sbassett triaged this task as Medium priority.

sbassett changed Author Affiliation from Other (Please specify in description) to Wikimedia Communities.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".

sbassett changed Risk Rating from N/A to Medium.

Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2023-37251: ⚓ T333980 GoogleAnalyticsMetrics extension - XSS

STW (aka Sensor-Technik Wiedemann) TCG-4 Connectivity Module DeploymentPackage_v3.03r0-Impala and DeploymentPackage_v3.04r2-Jellyfish and TCG-4lite Connectivity Module DeploymentPackage_v3.04r2-Jellyfish allow an attacker to gain full remote access with root privileges without the need for authentication, giving an attacker arbitrary remote code execution over LTE / 4G network via SMS.

Das Product Security Incident Response Team (PSIRT) von der Wiedemann Gruppe managt das Prüfen und Offenlegen von Sicherheitslücken und Schwachstellen. Sollte neues Gefährdungspotenzial im Zusammenhang mit unseren Softwareprodukten identifiziert werden, stellen wir umgehend Handlungsempfehlungen und/oder Updates zur Verfügung.

**Sicherheitslücken melden**

Helfen auch Sie mit, unsere Softwareprodukte noch sicherer zu machen. Das geht ganz einfach, indem Sie uns Schwachstellen und Gefährdungspotenzial melden.

Schicken Sie eine E-Mail an unser PSIRT (psirt(at)wiedemann-group.com) mit folgenden Informationen:

*   Produktlinie
*   anfällige Version
*   Art der Schwachstelle (Falls vorhanden inkl. CWE-ID, CVE-ID)
*   Name der Organisation
*   E-Mail
*   Telefon
*   Land

Da Informationen zu Sicherheitslücken und vermuteten Sicherheitslücken kritisch sind, möchten wir Sie bitten uns diese Informationen verschlüsselt zu übermitteln. Verwenden Sie daher unseren PGP- oder s/MIME-Schlüssel zum Verschlüsseln der Informationen, wenn Sie dem Wiedemann Group PSIRT eine potentielle Sicherheitslücke melden.

Wenn Sie zum ersten Mal mit dem Wiedemann Group PSIRT in Kontakt treten oder sich Ihr PGP- oder s/MIME-Schlüssel geändert hat, bitten wir Sie Ihren öffentlichen Schlüssel (public key) an Ihre initiale E-Mail anzuhängen, um verzögerungsfrei eine Ende-zu-Ende-Verschlüsselung zu ermöglichen.

**Product Security Incident Response**

Aktuelle Meldungen zu Schwachstellen von unseren Produkten und Security-Advisories

*   STW-IR-23-001

CVE-2023-35830: PSIRT | STW

An issue was discovered in the Cargo extension for MediaWiki through 1.39.3. XSS can occur in Special:CargoQuery via a crafted page item when using the default format.

**

Extension:Cargo XSS in Special:CargoQuery using default format

Closed, ResolvedPublicSecurity



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

Steps to reproduce:

Make a template Template:TextXSS:

<noinclude>{{#cargo\_declare: \_table=TestXSS
|field1=String (mandatory)
}}
</noinclude><includeonly>

Field1 is {{{field1}}}

{{#cargo\_store: \_table=TestXSS
|field1={{{field1}}}
}}
</includeonly>

And create the table.

Make a page Item:

{{TestXSS|field1=<script>alert(1)</script>}}

Go to Special:CargoQuery. Put table as TestXSS, field as TestXSS.field1. Keep format as (default). Hit submit, notice the popup box

Author Affiliation

Other (Please specify in description)

*   Mentions

**Event Timeline**

Comment Actions

I tested the fix, and can confirm that it seems to fix the issue.

I filed T331311 for a second thing i noticed while looking at the code.

Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2023-37254: ⚓ T331065 Extension:Cargo XSS in Special:CargoQuery using default format

An issue was discovered in the CheckUser extension for MediaWiki through 1.39.3. In Special:CheckUser, a check of the "get edits" type is vulnerable to HTML injection through the User-Agent HTTP request header.

**

Special:CheckUser 'get edits' is vulnerable to HTML injection through user agent string

Closed, ResolvedPublicSecurity



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

**Steps to reproduce**

*   Modify your user agent to include HTML
*   Make a test edit or logged action
*   Load Special:CheckUser
*   Run a check using the 'get edits' type
*   Notice that the HTML isn't escaped

**Example**  
Override your user agent string (example using Firefox about:config):  

Inspecting the logged edit using inspect element:

**Other information**  
The user agent is truncated before insertion into the database at 255 bytes which could make it harder to abuse. Only occurs when running the 'get edits' check type.

Risk Rating

Medium

Author Affiliation

Wikimedia Communities

*   Mentions

**Event Timeline**

Dreamy\_Jazz renamed this task from Special:CheckUser vulnerable to HTML injection through user agent string to Special:CheckUser 'get edits' is vulnerable to HTML injection through user agent string.Mar 30 2023, 2:44 PM

Comment Actions

> Please add a SECURITY: prefix to the commit message.

Done. Updated patch provided below:  

Comment Actions

Added prefix, will deploy now. I was able to reproduce the issue and test the fix locally.

0001-SECURITY-Escape-user-agent-before-showing-in-Special.patch1 KBDownload

Comment Actions

@Reedy I wonder if we can include this in the security release that you pre-announced yesterday? Or is this too short notice? (Security deployment is currently ongoing, btw.)

Comment Actions

This fix needs backporting to 1.39 and 1.40. 1.38 and before doesn't seem to have this problem.

Comment Actions

> This fix needs backporting to 1.39 and 1.40. 1.38 and before doesn't seem to have this problem.

Agreed, I just checked the same thing. (The bug was introduced in 6d6b229c02, the old code was using htmlspecialchars( $row->cuc\_agent ) and thus safe.)

Comment Actions

The fix should be deployed on wmf.1 and wmf.2 now. (I used deploy\_security.py.)

Comment Actions

Can verify this deployed correctly.

Was able to verify without the need to spoof my user agent to include HTML as there is separate bug with the template parser that makes the user agent not display if there is a specific character (which is how I found this issue) when the value is escaped. That issue is rare (only seen it once) and isn't a security issue. Will be looking for the associated task and if not filing one.

Comment Actions

Thanks all for the quick patch and deploy.

> @Reedy I wonder if we can include this in the security release that you pre-announced yesterday? Or is this too short notice? (Security deployment is currently ongoing, btw.)

Since CheckUser isn't bundled with core, it would go out as part of a supplemental security releases (current tracking bug: T325849). I don't know if I'd agree there's any sense of urgency here - anything within the supplemental release can be made public and have backports performed once the issue has been patched in Wikimedia production. So this issue could be a part of the _next_ supplemental security release, but be disclosed and backported much sooner.

Comment Actions

> So this issue could be a part of the _next_ supplemental security release, but be disclosed and backported much sooner.

Considering that users of the release branches will be pulling the changes soon, getting this merged into the release branches before the git pull is run makes sense to me. Therefore, given that this seems to be an okay thing once it's fixed in WMF production (which it has been), I'll do as such now.

A useful side effect of getting this fix out is that it makes fixing a non-security bug easier as this method of escaping seems to prevent some unicode characters being displayed (see T333573). The temporary fix (unless I can find the core issue) would be to use htmlspecialchars to escape the value. This method would conflict with the currently deployed security patch.

Comment Actions

> Considering that users of the release branches will be pulling the changes soon, getting this merged into the release branches before the git pull is run makes sense to me. Therefore, given that this seems to be an okay thing once it's fixed in WMF production (which it has been), I'll do as such now.

That's fine - I've got it tracked for the _next_ supplemental release: T333626. Completely fine to open this up and do backports now.

sbassett changed the task status from Open to In Progress.Apr 4 2023, 8:05 PM

sbassett triaged this task as Medium priority.

sbassett changed Author Affiliation from N/A to Wikimedia Communities.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".

sbassett changed Risk Rating from N/A to Medium.

Comment Actions

Unsure what else might need to be done before this can be marked as resolved (i.e. removing the patch on WMF systems), but the fix has been merged and backported to all supported versions that were vulnerable.

Comment Actions

> Unsure what else might need to be done before this can be marked as resolved (i.e. removing the patch on WMF systems), but the fix has been merged and backported to all supported versions that were vulnerable.

We track Wikimedia production patches on another task and Release Engineering has a step in the train that detects when such patches should fall off. So I think this can be resolved for now.

Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2023-37255: ⚓ T333569 Special:CheckUser 'get edits' is vulnerable to HTML injection through user agent string

An issue was discovered in the Cargo extension for MediaWiki through 1.39.3. It allows one to store javascript: URLs in URL fields, and automatically links these URLs.

**

Cargo allows storing javascript URLs in URL fields, and automatically linking them

Closed, ResolvedPublicSecurity



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

You can declare a cargo table with a field of type URL. You can then store urls like javascript:alert(1) in them. These urls can be malicious and a user could be tricked into clicking on them. Cargo should probably not allow storing javascript: scheme urls

Note: Its notoriously difficult to blacklist javascript: protocol urls, because browsers accept lots of variants. MediaWiki usually solves this problem by whitelisting good url protocols, although i don't know if cargo considers it acceptable to only allow a small set of good urls. Maybe cargo should allow everything, but only automatically link things that meet wfUrlProtocols();

Author Affiliation

Other (Please specify in description)

*   Mentions

**Event Timeline**

Bawolff changed Author Affiliation from N/A to Other (Please specify in description).Mar 6 2023, 5:54 PM

Comment Actions

I think you'd need to escape $value if $escapeValue is true.

Otherwise looks good.

Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2023-37256: ⚓ T331311 Cargo allows storing javascript URLs in URL fields, and automatically linking them

Deserialization of untrusted data in Microsoft Messaging Queuing Service in Medtronic's Paceart Optima versions 1.11 and earlier on Windows allows an unauthorized user to impact a healthcare delivery organization’s Paceart Optima system cardiac device causing data to be deleted, stolen, or modified, or the Paceart Optima system being used for further network penetration via network connectivity.

**Paceart Optima System Application Security Update**

**Summary**

Medtronic has identified a vulnerability in an optional messaging feature in the Paceart Optima cardiac device data workflow system. This feature is not configured by default, and it cannot be exploited unless enabled. As a precautionary measure, Medtronic is notifying customers that if exploited, this vulnerability could result in a healthcare delivery organization’s Paceart Optima system’s cardiac device data being deleted, stolen, or modified, or the Paceart Optima system being used for further network penetration.

Healthcare delivery organizations should work with Medtronic Paceart technical support to install an update to the Paceart Optima application to eliminate this vulnerability from the Paceart Application Server. This security bulletin also includes immediate, temporary steps for a healthcare delivery organization to take to prevent the exploitation of this vulnerability.

**Products impacted**

Paceart Optima™ is a software application that runs on a healthcare delivery organization’s Windows server. The application collects, stores, and retrieves cardiac device data from programmers and remote monitoring systems from all major cardiac device manufacturers to aid in standard workflows. The Paceart Optima product consists of multiple components that work together to deliver product functionality. This vulnerability impacts the Application Server component.

Versions affected:

*   Paceart Optima application versions 1.11 and earlier 

**Vulnerability Overview**

**At this time, Medtronic has not observed any cyberattacks, unauthorized access to or loss of patient data, or harm to patients related to this issue.**

During routine monitoring, Medtronic identified a vulnerability in the optional Paceart Messaging Service within the Paceart Optima system, specifically in the Paceart Messaging Service’s implementation of the Microsoft Message Queuing Protocol. The Paceart Messaging Service enables healthcare delivery organizations to send fax, email, and pager messages within the Paceart Optima system.

If a healthcare delivery organization has enabled the optional Paceart Messaging Service in the Paceart Optima system, an unauthorized user could exploit this vulnerability to perform Remote Code Execution (RCE) and/or Denial of Service (DoS) attacks by sending specially crafted messages to the Paceart Optima system. RCE could result in the Paceart Optima system’s cardiac device data being deleted, stolen, or modified, or the Paceart Optima system being used for further network penetration. A DoS attack could cause the Paceart Optima system to become slow or unresponsive.

The vulnerability is present in Paceart Optima system versions 1.11 and earlier.

**Recommended Actions****Immediate Mitigation Actions:**

_If you have a combined Application and Integration Server, contact Medtronic Paceart Optima system technical support for immediate mitigation actions. All other configurations, follow the steps below._

The vulnerable code will still be present in the application, but will no longer be exploitable.

Step 1: Manually disable the Paceart Messaging Service on the Application Server. 

1.  Open the ‘Windows Services’ application
2.  Find the ‘Paceart Messaging Service’
3.  Right-click the ‘Paceart Messaging Service’ and select ‘Properties’
4.  Select ‘Stop’ to stop running the service and change the startup type to ‘Disabled’
5.  Select ‘Apply’

Step 2: Manually disable message queuing on the Application Server. 

1.  Open server manager
2.  Select ‘Add roles and features’
3.  Select ‘Start the Remove Roles and Features Wizard’
4.  Before you begin – next
5.  Server selection – next
6.  Server roles – next
7.  Features section – take action. Select the black box next to Message Queuing
8.  When the window pops up select ‘Remove Features’ button
9.  Select ‘next’
10.  Confirmation – select ‘Remove’

As long as the Paceart Messaging Service remains disabled, the vulnerability will remain mitigated.

**Long-term Remediation Action:**

For a complete mitigation on the Application Server, update the Paceart Optima system to version 1.12. This update removes the Paceart Messaging Service function and fully remediates the vulnerability on the Application Server. To schedule an update, please reach out to dl.paceartupdate@medtronic.com.

If you are a patient and are concerned about care delivery associated with the Paceart Optima system, please consult your care provider.

**For more information:**

Contact for more support: Medtronic Paceart Optima system technical support  
1-800-PACEART (722-3278)

**Additional Details:**

Cybersecurity professionals may find the following technical information useful for tracking and risk rating purposes:

\-       The vulnerability has been assigned a CVE number, CVE-2023-31222 

\-       The CVSS score for this vulnerability is 9.8.

**Definitions:**

_**Remote Code Execution**_ – Remote code execution (RCE) is a type of security vulnerability that allows attackers to run arbitrary code on a remote machine if connected to it.

_**Denial of Service Attack**_ - A DoS is a type of cyberattack that is meant to shut down a machine, function or network, making it inaccessible to its intended users by consuming available resources with invalid activity. The most common DoS technique is to send invalid network requests that consume available network resources of an online service.

**_Exploit_ \-**An exploit is a program or methodology created to take advantage of a vulnerability in a system or product to gain unauthorized access or negatively affect proper operation.

**_Vulnerability_ –** A vulnerability is a weakness in systems, software or products that compromises security. A vulnerability allows people to perform bad actions on those same systems, software and products.

CVE-2023-31222: Paceart Optima System

JetBrains TeamCity 8 and 9 before 9.0.2 allows bypass of account-creation restrictions via a crafted request because the required request data can be deduced by reading HTML and JavaScript files that are returned to the web browser after an initial unauthenticated request.

CVE-2015-1313: Download TeamCity: Hassle-free CI and CD Server

An issue was discovered with the JSESSION IDs in Xiamen Si Xin Communication Technology Video management system 3.1 thru 4.1 allows attackers to gain escalated privileges.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

Source

CVE