Search
Find a vulnerability
Search criteria
1 vulnerability found for Content Solutions - SCHEMA ST4 by Quanos
GCVE-1988-2026-0369
Vulnerability from gna-1988 – Published: 2026-09-11 07:55 – Updated: 2026-09-11 11:31
VLAI
EPSS
VEX
Title
SEC Consult SA-20260617-1 :: Multiple Vulnerabilities in Quanos Content Solutions - SCHEMA ST4
Summary
SEC Consult Vulnerability Lab Security Advisory < 20260617-1 >
=======================================================================
title: Multiple Vulnerabilities
      product: Quanos Content Solutions - SCHEMA ST4
 vulnerable version: All versions of SCHEMA ST4 on-premises
  fixed version: Not applicable, see workaround section for mitigation.
CVE number: CVE-2026-11857, CVE-2026-11858
       impact: high
homepage:https://quanos.com/
       found: 2025-12-19
by: J. Kruchem (Office Vienna)
SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Atos business
Europe | Asia
https://www.sec-consult.com
=======================================================================
Vendor description:
-------------------
"SCHEMA ST4 is a component content management system for the professional
creation of technical documentation. SCHEMA ST4 is one of the most widely
used software solutions of its type and makes the entire creation process
easier and more efficient, saving costs in many areas."
Source:https://quanos.com/en/products/schema-st4/
Business recommendation:
------------------------
The vendor does not provide a patch but a workaround which requires
their customers to disable the affected "Client Update Service". Updating
the client is then only possible manually with a privileged user account.
SEC Consult highly recommends to perform a thorough security review of the product
conducted by security professionals to identify and resolve potential further
security issues.
Vulnerability overview/description:
-----------------------------------
1) .NET Remoting Local Privilege Escalation Vulnerability (CVE-2026-11857)
A local privilege escalation vulnerability exists in SCHEMA ST4 due to insecure
deserialization in the .NET Remoting service.
The service is configured with TypeFilterLevel.Full and bound to local interfaces
only (named pipes), allowing a local authenticated attacker to send specially crafted
objects. This leads to arbitrary code execution in the context of the update process
with the highest SYSTEM rights. Local host access with an authenticated user session
is required for successful exploitation. Network-only exploitation is not possible.
2) Arbitrary File Overwrite Vulnerability (CVE-2026-11858)
The SCHEMA ST4 Update Service acts as a privileged helper component running as
NT Authority\SYSTEM to perform file operations requiring elevated rights.
However, it exposes a .NET Remoting interface over a Named Pipe without sufficient
access controls or authentication. This allows any local low-privileged user to
connect and invoke methods like Update(), resulting in arbitrary file
write/delete operations with SYSTEM privileges. This ultimately leads to local
privilege escalation.
Proof of concept:
-----------------
The following steps can be taken in order to exploit the identified security issue
in the updater service.
1) .NET Remoting Local Privilege Escalation Vulnerability (CVE-2026-11857)
1.1) Connect to Name Pipe
Invoking NamedPipe.ConnectToPipe("ST4Updater2") and sending pipe.Write("init")
returns a port which is used for .NET Remoting. Only local exploitation is
possible.
1.2) Send .NET Remoting payload
Use the ExploitRemotingService by James Forshaw (https://github.com/tyranid/ExploitRemotingService)
to achieve arbitrary code execution.
2) Arbitrary File Overwrite Vulnerability (CVE-2026-11858)
2.1) Connect to Named Pipe
Invoking NamedPipe.ConnectToPipe("ST4Updater2") and sending pipe.Write("init")
returns a port which is used for .NET Remoting.
2.2) Get .NET Remoting Object
Get remote object tcp://127.0.0.1:<port>/UpdateProcessCore
2.3) Create Manifest
An essential part of the exploit is creating a Manifest.rdf containing e.g.
Directory "." and file exploit.exe:<something like md5> (is not checked).
The Manifest needs to be zlib-compressed and be served via HTTP.
2.4) Create Payload
Create a zlib-compressed file (e.g. .exe, .msi, .dll, ...) name it to
your choosing like <e.g. md5> and put it into the HTTP root (like
the Manifest).
2.5) Invoke Update() from remote .NET object
Use the object from 2.2) and provide proper arguments.
Use "Newer" for writing files as system (same name will be deleted beforehands)
Use "Remove" for deleting files and/or directories (depending on Manifest)
Example:
[ Proof of Concept example removed ]
2.6) Privilege Escalation
To achieve privilege escalation e.g. write a custom HID.dll using the exploit to
C:\Program Files\Common Files\microsoft shared\ink\ then open the Microsoft
on-screen keyboard in a security context (e.g. CTRL + ALT + ENTF). The custom
commands are executed with SYSTEM privileges.
[ ST4Updater.png ]
Figure 1: Proof of concept
Vulnerable / tested versions:
-----------------------------
The following version has been tested:
* 12.0.4.0 ST4 2022 SP4 (1d4a0bde) ??? SCHEMA ST4 12.4 build 2023.02.21-1d4a0bde
According to the vendor, all versions of SCHEMA ST4 on-premises are affected.
The Cloud/SaaS deployments of SCHEMA ST4 are not affected. The Client Update
Service has been removed in the cloud architecture according to the vendor.
Vendor contact timeline:
------------------------
2025-12-19: Contacting vendor throughinfo () quanos com; no response
2026-01-13: Contacting CISO through LinkedIn. Response after 1 Minute (at 7 pm).
2026-01-14: Sending more details via email tosecurity () quanos com;
Vendor answers that they will analyze our information and will get
back to us.
Asking the vendor how we should submit our security advisory.
2026-01-22: Vendor responds that the architecture of ST4 is by design and only
exploitable within the on premises version of ST4 (not cloud/SaaS).
Provides a workaround to disable the client update service.
2026-01-23: Updating our advisory regarding workaround, recommending to patch
the issue, as also .NET remoting can be exploited. Asking whether
the on premises version is EOL.
2026-01-28: Vendor responds to clarify our questions internally.
2026-02-09: Asking for a status update.
2026-02-10: Vendor is still waiting for an internal response.
2026-03-05: Asking for a status update.
2026-03-10: Vendor is still in internal clarification process.
2026-03-20: Vendor provides detailed explanation regarding "Client Update "Service",
which already got removed in the Cloud/SaaS solution, on-premises exploitation
is impossible in properly managed environments according to the vendor.
As a workaround, the Update Service should be disabled. The .NET Remoting
part only communicates in a closed VPC network within the Cloud solution.
An attacker already needs LAN access for the on-premises version and exploitation
is therefore limited according to the vendor. Vendor suggests to include
their assessment of the case in our advisory.
2026-03-20: Response to the vendor that the attack path for the "Client Update Service"
is to escalate privileges from a low-privileged user to admin. In order to
exploit .NET Remoting, host access is also required. Asking for affected
versions and whether no update will be provided except the workaround.
2026-04-08: Vendor responds with affected versions and details on workaround
implications for end users
2026-06-10: Informing vendor about upcoming release for 16th June, providing reserved
CVE numbers.
2026-06-12: Vendor responds that they will provide feedback on 15th June.
2026-06-15: Asking the vendor regarding the feedback, as we did not receive it (late
afternoon). Vendor responds that they are still working on the feedback.
Vendor submits feedback in the evening.
2026-06-16: Responding to feedback, adjusted advisory.
2026-06-17: Public release of security advisory.
Solution:
---------
The vendor does not provide a patch but a workaround which requires
their customers to disable the "Client Update Service". Updating the client
is then only possible with a privileged user account.
The vendor provided the following statement:
"Quanos confirms that exploitation requires local host access with an
authenticated user session. In properly managed environments following the
Least Privilege principle, the attack surface is significantly reduced.
Quanos Cloud/SaaS deployments are not affected. Quanos considers the
migration to the Cloud/SaaS architecture the strategic long-term solution."
Workaround:
-----------
Disable the "Client-Updateservice" until a fix is provided.
Advisory URL:
-------------
https://sec-consult.com/vulnerability-lab/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Atos business
Europe | Asia
About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an
Atos business. It ensures the continued knowledge gain of SEC Consult in the
field of network and application security to stay ahead of the attacker. The
SEC Consult Vulnerability Lab supports high-quality penetration testing and
the evaluation of new offensive and defensive technologies for our customers.
Hence our customers obtain the most current information about vulnerabilities
and valid recommendation about the risk profile of new technologies.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your applicationhttps://sec-consult.com/career/
Interested in improving your cyber security with the experts of SEC Consult?
Contact our local officeshttps://sec-consult.com/contact/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mail: security-research at sec-consult dot com
Web:https://www.sec-consult.com
Blog:https://blog.sec-consult.com
X:https://x.com/sec_consult
EOF J. Kruchem / @2026
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/
Severity
No CVSS data available.
Assigner
References
13 references
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Quanos | Content Solutions - SCHEMA ST4 |
Affected:
unknown
|
Relationships
analysis
GCVE-1988-2026-0369 (this record)
- related CVE-2026-11857
- related CVE-2026-11858
{
"containers": {
"cna": {
"affected": [
{
"product": "Content Solutions - SCHEMA ST4",
"vendor": "Quanos",
"versions": [
{
"status": "affected",
"version": "unknown"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "SEC Consult Vulnerability Lab via Fulldisclosure"
}
],
"descriptions": [
{
"lang": "en",
"value": "SEC Consult Vulnerability Lab Security Advisory \u003c 20260617-1 \u003e\n=======================================================================\n title: Multiple Vulnerabilities\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 product: Quanos Content Solutions - SCHEMA ST4\n\u00a0vulnerable version: All versions of SCHEMA ST4 on-premises\n \u00a0 \u00a0 fixed version: Not applicable, see workaround section for mitigation.\n CVE number: CVE-2026-11857, CVE-2026-11858\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0impact: high\n homepage:https://quanos.com/\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 found: 2025-12-19\n by: J. Kruchem (Office Vienna)\n SEC Consult Vulnerability Lab\n\n An integrated part of SEC Consult, an Atos business\n Europe | Asia\n\n https://www.sec-consult.com\n\n=======================================================================\n\nVendor description:\n-------------------\n\"SCHEMA ST4 is a component content management system for the professional\ncreation of technical documentation. SCHEMA ST4 is one of the most widely\nused software solutions of its type and makes the entire creation process\neasier and more efficient, saving costs in many areas.\"\n\nSource:https://quanos.com/en/products/schema-st4/\n\n\nBusiness recommendation:\n------------------------\nThe vendor does not provide a patch but a workaround which requires\ntheir customers to disable the affected \"Client Update Service\". Updating\nthe client is then only possible manually with a privileged user account.\n\nSEC Consult highly recommends to perform a thorough security review of the product\nconducted by security professionals to identify and resolve potential further\nsecurity issues.\n\n\nVulnerability overview/description:\n-----------------------------------\n1) .NET Remoting Local Privilege Escalation Vulnerability (CVE-2026-11857)\nA local privilege escalation vulnerability exists in SCHEMA ST4 due to insecure\ndeserialization in the .NET Remoting service.\n\nThe service is configured with TypeFilterLevel.Full and bound to local interfaces\nonly (named pipes), allowing a local authenticated attacker to send specially crafted\nobjects. This leads to arbitrary code execution in the context of the update process\nwith the highest SYSTEM rights. Local host access with an authenticated user session\nis required for successful exploitation. Network-only exploitation is not possible.\n\n2) Arbitrary File Overwrite Vulnerability (CVE-2026-11858)\nThe SCHEMA ST4 Update Service acts as a privileged helper component running as\nNT Authority\\SYSTEM to perform file operations requiring elevated rights.\n\nHowever, it exposes a .NET Remoting interface over a Named Pipe without sufficient\naccess controls or authentication. This allows any local low-privileged user to\nconnect and invoke methods like Update(), resulting in arbitrary file\nwrite/delete operations with SYSTEM privileges. This ultimately leads to local\nprivilege escalation.\n\n\nProof of concept:\n-----------------\nThe following steps can be taken in order to exploit the identified security issue\nin the updater service.\n\n1) .NET Remoting Local Privilege Escalation Vulnerability (CVE-2026-11857)\n1.1) Connect to Name Pipe\nInvoking NamedPipe.ConnectToPipe(\"ST4Updater2\") and sending pipe.Write(\"init\")\nreturns a port which is used for .NET Remoting. Only local exploitation is\npossible.\n\n1.2) Send .NET Remoting payload\nUse the ExploitRemotingService by James Forshaw (https://github.com/tyranid/ExploitRemotingService)\nto achieve arbitrary code execution.\n\n\n2) Arbitrary File Overwrite Vulnerability (CVE-2026-11858)\n2.1) Connect to Named Pipe\nInvoking NamedPipe.ConnectToPipe(\"ST4Updater2\") and sending pipe.Write(\"init\")\nreturns a port which is used for .NET Remoting.\n\n2.2) Get .NET Remoting Object\nGet remote object tcp://127.0.0.1:\u003cport\u003e/UpdateProcessCore\n\n2.3) Create Manifest\nAn essential part of the exploit is creating a Manifest.rdf containing e.g.\nDirectory \".\" and file exploit.exe:\u003csomething like md5\u003e (is not checked).\nThe Manifest needs to be zlib-compressed and be served via HTTP.\n\n2.4) Create Payload\nCreate a zlib-compressed file (e.g. .exe, .msi, .dll, ...) name it to\nyour choosing like \u003ce.g. md5\u003e and put it into the HTTP root (like\nthe Manifest).\n\n2.5) Invoke Update() from remote .NET object\nUse the object from 2.2) and provide proper arguments.\nUse \"Newer\" for writing files as system (same name will be deleted beforehands)\nUse \"Remove\" for deleting files and/or directories (depending on Manifest)\n\nExample:\n[ Proof of Concept example removed ]\n\n2.6) Privilege Escalation\nTo achieve privilege escalation e.g. write a custom HID.dll using the exploit to\nC:\\Program Files\\Common Files\\microsoft shared\\ink\\ then open the Microsoft\non-screen keyboard in a security context (e.g. CTRL + ALT + ENTF). The custom\ncommands are executed with SYSTEM privileges.\n\n[ ST4Updater.png ]\nFigure 1: Proof of concept\n\n\nVulnerable / tested versions:\n-----------------------------\nThe following version has been tested:\n* 12.0.4.0 ST4 2022 SP4 (1d4a0bde) ??? SCHEMA ST4 12.4 build 2023.02.21-1d4a0bde\n\nAccording to the vendor, all versions of SCHEMA ST4 on-premises are affected.\nThe Cloud/SaaS deployments of SCHEMA ST4 are not affected. The Client Update\nService has been removed in the cloud architecture according to the vendor.\n\n\nVendor contact timeline:\n------------------------\n2025-12-19: Contacting vendor throughinfo () quanos com; no response\n2026-01-13: Contacting CISO through LinkedIn. Response after 1 Minute (at 7 pm).\n2026-01-14: Sending more details via email tosecurity () quanos com;\n Vendor answers that they will analyze our information and will get\n back to us.\n Asking the vendor how we should submit our security advisory.\n2026-01-22: Vendor responds that the architecture of ST4 is by design and only\n exploitable within the on premises version of ST4 (not cloud/SaaS).\n Provides a workaround to disable the client update service.\n2026-01-23: Updating our advisory regarding workaround, recommending to patch\n the issue, as also .NET remoting can be exploited. Asking whether\n the on premises version is EOL.\n2026-01-28: Vendor responds to clarify our questions internally.\n2026-02-09: Asking for a status update.\n2026-02-10: Vendor is still waiting for an internal response.\n2026-03-05: Asking for a status update.\n2026-03-10: Vendor is still in internal clarification process.\n2026-03-20: Vendor provides detailed explanation regarding \"Client Update \"Service\",\n which already got removed in the Cloud/SaaS solution, on-premises exploitation\n is impossible in properly managed environments according to the vendor.\n As a workaround, the Update Service should be disabled. The .NET Remoting\n part only communicates in a closed VPC network within the Cloud solution.\n An attacker already needs LAN access for the on-premises version and exploitation\n is therefore limited according to the vendor. Vendor suggests to include\n their assessment of the case in our advisory.\n2026-03-20: Response to the vendor that the attack path for the \"Client Update Service\"\n is to escalate privileges from a low-privileged user to admin. In order to\n exploit .NET Remoting, host access is also required. Asking for affected\n versions and whether no update will be provided except the workaround.\n2026-04-08: Vendor responds with affected versions and details on workaround\n implications for end users\n2026-06-10: Informing vendor about upcoming release for 16th June, providing reserved\n CVE numbers.\n2026-06-12: Vendor responds that they will provide feedback on 15th June.\n2026-06-15: Asking the vendor regarding the feedback, as we did not receive it (late\n afternoon). Vendor responds that they are still working on the feedback.\n Vendor submits feedback in the evening.\n2026-06-16: Responding to feedback, adjusted advisory.\n2026-06-17: Public release of security advisory.\n\n\nSolution:\n---------\nThe vendor does not provide a patch but a workaround which requires\ntheir customers to disable the \"Client Update Service\". Updating the client\nis then only possible with a privileged user account.\n\nThe vendor provided the following statement:\n\"Quanos confirms that exploitation requires local host access with an\nauthenticated user session. In properly managed environments following the\nLeast Privilege principle, the attack surface is significantly reduced.\nQuanos Cloud/SaaS deployments are not affected. Quanos considers the\nmigration to the Cloud/SaaS architecture the strategic long-term solution.\"\n\n\nWorkaround:\n-----------\nDisable the \"Client-Updateservice\" until a fix is provided.\n\n\nAdvisory URL:\n-------------\nhttps://sec-consult.com/vulnerability-lab/\n\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nSEC Consult Vulnerability Lab\nAn integrated part of SEC Consult, an Atos business\nEurope | Asia\n\nAbout SEC Consult Vulnerability Lab\nThe SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an\nAtos business. It ensures the continued knowledge gain of SEC Consult in the\nfield of network and application security to stay ahead of the attacker. The\nSEC Consult Vulnerability Lab supports high-quality penetration testing and\nthe evaluation of new offensive and defensive technologies for our customers.\nHence our customers obtain the most current information about vulnerabilities\nand valid recommendation about the risk profile of new technologies.\n\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nInterested to work with the experts of SEC Consult?\nSend us your applicationhttps://sec-consult.com/career/\n\nInterested in improving your cyber security with the experts of SEC Consult?\nContact our local officeshttps://sec-consult.com/contact/\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nMail: security-research at sec-consult dot com\nWeb:https://www.sec-consult.com\nBlog:https://blog.sec-consult.com\nX:https://x.com/sec_consult\n\nEOF J. Kruchem / @2026\n\n_______________________________________________\nSent through the Full Disclosure mailing list\nhttps://nmap.org/mailman/listinfo/fulldisclosure\nWeb Archives \u0026 RSS: https://seclists.org/fulldisclosure/"
}
],
"providerMetadata": {
"dateUpdated": "2026-09-11T11:31:42Z",
"orgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"shortName": "VULNARCHIVE"
},
"references": [
{
"tags": [
"technical-description",
"exploit"
],
"url": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jun/20"
},
{
"tags": [
"technical-description"
],
"url": "https://seclists.org/fulldisclosure/2026/Jun/20"
},
{
"url": "https://blog.sec-consult.com"
},
{
"url": "https://github.com/tyranid/ExploitRemotingService"
},
{
"url": "https://nmap.org/mailman/listinfo/fulldisclosure"
},
{
"url": "https://quanos.com/"
},
{
"url": "https://quanos.com/en/products/schema-st4/"
},
{
"url": "https://sec-consult.com/career/"
},
{
"url": "https://sec-consult.com/contact/"
},
{
"url": "https://sec-consult.com/vulnerability-lab/"
},
{
"url": "https://seclists.org/fulldisclosure/"
},
{
"url": "https://www.sec-consult.com"
},
{
"url": "https://x.com/sec_consult"
}
],
"source": {
"defect": [
"https://seclists.org/fulldisclosure/2026/Jun/20"
],
"discovery": "EXTERNAL"
},
"title": "SEC Consult SA-20260617-1 :: Multiple Vulnerabilities in Quanos Content Solutions - SCHEMA ST4",
"x_gcve": [
{
"recordType": "analysis",
"relationships": [
{
"destId": "CVE-2026-11857",
"type": "related"
},
{
"destId": "CVE-2026-11858",
"type": "related"
}
],
"vulnId": "GCVE-1988-2026-0369",
"x_vulnarchive": {
"archiveUrl": "https://vuln.freearchive.org/archive/full-disclosure/2026/Jun/20",
"automated": true,
"contentSha256": "ea5956e54077d750b908be7c84ab2859939c89d63375abf670487dd7fbbd170b",
"evidenceScore": 9,
"messageId": "",
"originalUrl": "https://seclists.org/fulldisclosure/2026/Jun/20",
"policy": "vulnarchive-1",
"sourceFormat": "text/html",
"sourcePublishedAt": "2026-06-17T11:31:26Z"
}
},
{
"recordType": "advisory",
"vulnId": "gcve-1988-2026-0369"
}
]
}
},
"cveMetadata": {
"assignerOrgId": "4e2abfbf-4a2a-4b76-a4e0-d77c18ba156c",
"assignerShortName": "VULNARCHIVE",
"datePublished": "2026-09-11T07:55:58Z",
"dateUpdated": "2026-09-11T11:31:42Z",
"state": "PUBLISHED",
"vulnId": "GCVE-1988-2026-0369"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}