CVE-2021-41553
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn ARCHIBUS Web Central 21.3.3.815 (a version from 2014), the Web Application in /archibus/login.axvw assign a session token that could be already in use by another user. It was therefore possible to access the application through a user whose credentials were not known, without any attempt by the testers to modify the application logic. It is also possible to set the value of the session token, client-side, simply by making an unauthenticated GET Request to the Home Page and adding an arbitrary value to the JSESSIONID field. The application, following the login, does not assign a new token, continuing to keep the inserted one, as the identifier of the entire session. This is fixed in all recent versions, such as version 26. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. Version 21.3 was officially de-supported by the end of 2020
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceSession fixation vulnerability in ARCHIBUS Web Central allows attackers to pre-set the JSESSIONID cookie value before authentication. The application accepts arbitrary session tokens and continues using the attacker-provided token after successful login, enabling complete session hijacking without knowing user credentials.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data= 21.3.3.815CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify installed ARCHIBUS Web Central versionCheck the application version by viewing the login page source, checking server banners, or looking for version files in the web application directory (such as version.properties or manifest files in the WEB-INF folder)Affected if The installed version is 21.3.3.815 specifically
-
Verify JSESSIONID cookie behavior before authenticationUsing a browser or HTTP tool (such as Burp Suite or curl), make a request to the ARCHIBUS login page without authenticating and inspect the response headers for Set-Cookie containing JSESSIONID. Then make another unauthenticated request and observe if the same JSESSIONID value persists across requestsAffected if The application sets a JSESSIONID cookie before authentication and accepts the same token across multiple unauthenticated requests
-
Confirm session token regeneration is not occurring after loginStart a new browser session, capture the initial JSESSIONID value, then authenticate with valid credentials and inspect whether the JSESSIONID changes after successful authentication. Compare the cookie value before and after loginAffected if The JSESSIONID value remains the same before and after successful authentication, indicating no session regeneration occurs
-
Check for session fixation protection in server configurationExamine the application server configuration (typically in server.xml for Tomcat or equivalent for other servers) for session settings. Look for session-config elements and check if any session fixation protection (such as changeSessionId() on authentication) is configuredAffected if No session fixation protection mechanisms are configured and the server allows client-supplied session IDs
You are affected if running ARCHIBUS Web Central version 21.3.3.815 and the application accepts and retains attacker-controlled JSESSIONID values through the authentication process without regenerating the session identifier.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade to version 26 or later (supported release). If upgrading is not feasible due to product de-support, implement server-side session token regeneration after authentication and invalidate old sessions.
ARCHIBUS Web Central version 26 or later (the description states version 26 contains the fix)
- 1. Verify current installation of ARCHIBUS Web Central version 21.3.3.815
- 2. Obtain ARCHIBUS version 26 or later from official vendor channels (my.archibus.com or through authorized support)
- 3. Review the official upgrade guide for version 26 for your specific deployment type
- 4. Perform a full backup of the existing database and application files before upgrading
- 5. Stop the application server hosting ARCHIBUS Web Central
- 6. Execute the upgrade installer following vendor documentation
- 7. Verify the JSESSIONID behavior: confirm new sessions receive freshly generated tokens and existing tokens are not reused after authentication
- 8. Test application functionality post-upgrade to ensure all features work correctly
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation8.0 h
- Implementation24.0 h
- Testing16.0 h
- Review / QA8.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $15,616.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2021-41553 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2021-41553 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data