CVE-2023-6451 is a high severity authentication flaw in AlayaCare Procura Portal. A cryptographic machine key that is publicly known lets attackers forge their own authentication cookies and bypass login. The record says versions before 9.0.1.2 are affected, so upgrade to 9.0.1.2 or later.
What's affected
- Product: AlayaCare Procura Portal.
- Affected: versions before 9.0.1.2, per the record.
- Fixed: 9.0.1.2.
- Scope: the vector shows a changed scope, with a confidentiality impact.
The record gives a CVSS 3.1 base score of 8.6 (high) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N. The CISA Known Exploited Vulnerabilities flag in the record is false. This post does not claim exploitation in the wild.
How to check if you're exposed
Check the Procura Portal version in the application or with the vendor. If you host it yourself, compare with 9.0.1.2.
Also ask whether the machine key in the configuration is the one that shipped with the product. A key that is shared across installations should be treated as public. After upgrading, confirm with the vendor whether a new key is generated or whether you must set one.
What to do now
- Confirm the Procura Portal version in each environment.
- Upgrade to 9.0.1.2 or later.
- Ask the vendor how to replace the machine key, and replace it with a unique one if the upgrade does not.
- Invalidate existing sessions after the key change so forged cookies stop working.
- Review authentication logs for sessions that do not match a normal login.
- Run the free in-browser dependency scan at gold.safeguard.sh/scan on any project you build that bundles this component, and keep the result next to your inventory.
Why it matters
The record maps this issue to CWE-1394 (Use of Default Cryptographic Key): A cryptographic key that ships with the product, or is publicly known, protects something that should be secret. ; CWE-287 (Improper Authentication): The application does not properly prove that a caller is who they claim to be.
The record lists use of a default cryptographic key and improper authentication. Authentication cookies are protected by a key held by the server. If that key is known, anyone can produce a cookie that the server accepts as valid, with no password involved.
The danger of a shared key is that it cannot be fixed by one customer alone, since every installation holds the same secret. The fix has two parts, a patched version and a unique key. Without the second part, the first is only partly effective, so ask the vendor to confirm both.
Quick check
Do forged cookies need an account?
The record says attackers forge their own cookies and bypass authentication, so no valid credentials are described as needed.
Is upgrading enough?
Upgrade, then confirm with the vendor that the machine key was replaced and sessions were reset.
Sources
These are the references listed in the NVD record for this CVE. They were not fetched when this post was written, so confirm fixed versions in the advisory before acting.
Last reviewed: 19 October 2026.
