get_version() parses a <prefix> element that does not exist in the UDS API

[bandrel]

Summary

get_version() parses a <prefix> element out of the /cucm-uds/version response, and main() prints it to the operator. UDS has no <prefix> element. The string "prefix" does not appear anywhere in Cisco's UDS documentation — not the current /docs/ reference, not the legacy /site/ API reference, not the developer guide.

The complete documented response is:

<versionInformation uri="https://{host}/cucm-uds/version" version="10.0.0">
  <version>11.5.1</version>
  <capabilities>
    <usersResourceAuthEnabled>true</usersResourceAuthEnabled>
  </capabilities>
</versionInformation>

That is the entire element list: <versionInformation> with uri and version attributes, <version>, and <capabilities> → <usersResourceAuthEnabled>.

Effect

info['prefix'] is never populated against a real cluster, so the operator-facing print at thief.py:2932 is permanently dead. It is only ever populated by the _TEST_MODE stub ('prefix': '11.0(1)'), which means any test asserting on it is asserting on a fiction and gives false confidence that the field works.

Fix

Drop prefix from the parse loop, from the _TEST_MODE dict, and from the main() output. If the intent was to surface the wrapper's version attribute (the UDS schema version, e.g. 10.0.0, distinct from the CUCM version in the <version> element), that is a genuinely useful thing to report and would be worth parsing under an accurate name — but it is an attribute on <versionInformation>, not a child element.

Second, real version-dependency in the same function

<capabilities> was introduced in 11.5(1). The legacy CUCM 10.x reference documents the response with no <capabilities> block at all. The current code handles this correctly by accident — the auth_m regex simply does not match and usersAuthRequired stays absent from the dict, so version_info.get('usersAuthRequired') is falsey. That is the right behavior, but it is undocumented and one refactor away from becoming a KeyError. Worth a comment stating that a missing flag means "pre-11.5(1), auth not enforceable" rather than "unknown".

[bandrel]

Follow-up: corroborated by a live-tested detection template, and the likely transcription error

Re-checked against sources beyond the developer.cisco.com prose docs.

Independent confirmation. ProjectDiscovery's cisco-ucm-version.yaml — marked verified: true, i.e. validated against live CUCM hosts — matches only <versionInformation plus <version> and extracts xpath /versionInformation/version. No <prefix>, no other children. That is real-world capture evidence, independent of Cisco's docs.

Origin of the field. git log -S "<prefix>" returns exactly one commit: 337d179, the Contact Search Authentication hardening. prefix was introduced there with no doc citation and no captured response body. That commit's message notes the version endpoint was confirmed reachable on a live CUCM 14.0.1 target — but only reachability was recorded, not the body, so nothing in our history evidences a <prefix> element on any release.

Most likely explanation: conflation with the version= attribute on the <versionInformation> root, which Cisco's own examples show can differ from the <version> child element (version="10.0.0" on the wrapper vs <version>11.5.1</version> inside). That attribute is the UDS schema version, and reporting it alongside the CUCM version is genuinely useful — so the fix may be to parse that attribute under an accurate name rather than simply deleting the field. A secondary possibility is contamination from the MAC-prefix handling elsewhere in the same file.

Doc-coverage note: there is no newer UDS prose doc set to check — no version selector, no per-release guide, and www.cisco.com 403s automated fetches. A v14 version.get.xsd does exist in the UDS XML Schema for v14 bundle, which would settle the element list conclusively for 14; it requires a DevNet login to download. See #36 for the same gating.

[bandrel]

RESOLVED by primary source: the official v14 XSD

From UDS-xsd-14.zip (DevNet schema downloads, DevNet login required), xsd/pub/version/version.get.xsd in full:

<xs:complexType name="capabilities">
    <xs:sequence>
        <xs:element name="usersResourceAuthEnabled" type="xs:boolean"/>
        <xs:element name="upgradeInProgress" type="xs:boolean"/>
    </xs:sequence>
</xs:complexType>

<xs:element name="versionInformation">
    <xs:complexType>
        <xs:sequence>
            <xs:element name="version" type="xs:string"/>
            <xs:element name="capabilities" type="capabilities"/>
        </xs:sequence>
        <xs:attribute name="uri" type="xs:anyURI" use="required"/>
        <xs:attribute name="version" type="xs:string" use="required"/>
    </xs:complexType>
</xs:element>

There is no <prefix> element on CUCM 14, and the schema permits no elements beyond <version> and <capabilities>. Confirmed: delete the field.

Three further facts this settles:

1. The spelling is usersResourceAuthEnabled (plural users). Our regex is correct. The singular userResourceAuthEnabled / <userResourceEnabled> spellings in Cisco's prose are documentation typos, not release variants — no defensive multi-spelling matching is needed.
2. <capabilities> is mandatory in v14 (no minOccurs="0"), so on 14+ the flag is always present. It is still absent pre-11.5(1), so the current "missing means falsey" behavior remains right — but it is worth the comment proposed in the issue body, since the reason differs by release.
3. The version= attribute on <versionInformation> is use="required" and is distinct from the <version> child. The schema even names it explicitly via a JAXB binding: <jaxb:property name="versionAttribute"/>. That confirms the theory in my earlier comment — parsing it under an accurate name (uds_schema_version or similar) is the better fix than deleting the field outright, and it always exists so it will never be empty.

New finding, filed separately as #37: the v14 schema also defines <upgradeInProgress>, a capability flag that appears in no Cisco prose documentation. We do not parse it.