CVE-2023-6329

What it actually does

The flaw is an authentication bypass in Control iD iDSecure v4.7.32.0. The login logic in iDS-Core.dll supports a passwordCustom option that allows an unauthenticated remote attacker to derive or submit credentials accepted by the application, resulting in administrative access without knowing a legitimate password. Because the issue is network-reachable, low-complexity, requires no prior privileges, and can provide administrative control, it has full confidentiality, integrity, and availability impact.

Why it matters to the business

A successful exploit can let an attacker take over the iDSecure administration interface, change access-control settings, view or modify sensitive identity and attendance data, create or alter users, disrupt physical access operations, and potentially pivot further into connected infrastructure. The vulnerability is high urgency because it is weaponized, has a high EPSS likelihood of exploitation, and has been public for a long period, increasing the chance that exposed systems have already been scanned or targeted. It is not currently listed in CISA KEV and is not specifically flagged as ransomware-used in the provided data, but the practical impact remains severe for any internet-exposed or broadly reachable deployment.

How an attack unfolds

An attacker first discovers an exposed iDSecure instance or a reachable management interface. They then interact with the login workflow and supply or trigger the passwordCustom authentication path handled by iDS-Core.dll. By computing or crafting values that the application treats as valid credentials, the attacker obtains an administrative session without possessing a legitimate password. Once authenticated as an administrator, they can alter configuration, add accounts, modify access policies, extract sensitive records, or use the compromised application as a foothold for further reconnaissance and lateral movement. Because weaponized exploitation is reported, defenders should assume working exploit logic is available and prioritize both patching and retrospective review.

How to fix it

Upgrade Control iD iDSecure to a vendor-fixed release that removes or corrects the vulnerable passwordCustom authentication behavior; v4.7.32.0 should be treated as vulnerable. Restrict access to the iDSecure administrative interface to trusted management networks or VPNs, block direct internet exposure, and enforce network-layer access controls while patching is underway. Review and rotate administrative credentials and API secrets after remediation because exploitation can create valid administrative access without normal password use. Audit administrator accounts, access policies, and configuration changes for unauthorized modifications. Where this CVE is being tracked through Debian package remediation data, ensure Debian 12 systems are updated to at least 6.1.90-1 and Debian 13 systems are updated to at least 6.8.9-1, then reboot if required for the updated components to take effect.

How to confirm the fix worked

Confirm the deployed iDSecure version is newer than the vulnerable v4.7.32.0 release or that the vendor-provided hotfix is installed. Verify the vulnerable iDS-Core.dll has been replaced with a fixed build according to the vendor advisory. Attempt a controlled authentication test against the login workflow to ensure requests using passwordCustom or equivalent crafted values are rejected and logged rather than accepted. Confirm the administrative interface is not reachable from untrusted networks. On Debian-tracked assets, validate installed package versions with the system package manager and confirm Debian 12 is at 6.1.90-1 or later and Debian 13 is at 6.8.9-1 or later. Review application logs after patching to ensure no unexpected administrative sessions continue to appear.

Typical attack path

1. Identify an exposed or reachable Control iD iDSecure service, commonly through internet scanning, asset discovery, or internal reconnaissance.
2. Access the authentication endpoint or login workflow used by the iDSecure management application.
3. Submit crafted authentication data that invokes or abuses the passwordCustom option processed by iDS-Core.dll.
4. Receive a valid administrative session or token without knowing a legitimate administrator password.
5. Use administrative access to create or modify users, change access-control configuration, export data, or disable security controls.
6. Optionally establish persistence by creating additional administrator accounts, changing service settings, or staging follow-on tooling.

How to detect it

Perform retrospective hunting across application logs, web server logs, reverse proxy logs, WAF events, endpoint telemetry, and identity/audit logs associated with iDSecure. Look for HTTP requests or form submissions containing passwordCustom, especially when followed by successful administrator sessions. Correlate successful administrative logins with normal authentication events; suspicious cases include admin sessions with no preceding password validation, logins from unfamiliar IP addresses, unusual user agents, off-hours access, or rapid configuration changes immediately after login. Review audit trails for new administrator accounts, password changes, permission changes, access-policy modifications, device enrollment changes, and bulk exports. On hosts, check iDSecure installation directories for unexpected changes to iDS-Core.dll, newly added binaries or scripts, modified service configuration, and unusual child processes spawned by the application service. If logs are limited, use network telemetry or proxy records to identify requests containing passwordCustom and sessions that reach administrative URLs shortly afterward.

• passwordCustom
• iDS-Core.dll
• iDSecure
• /login
• /admin
• POST /login
• passwordCustom=
• passwordCustom%3D

What your security team should do

• Immediately identify all Control iD iDSecure deployments and determine whether any are running v4.7.32.0 or an unconfirmed build.
• Prioritize patching or vendor hotfix deployment because exploitation is weaponized and the EPSS score indicates substantial real-world exploitation likelihood.
• Remove direct internet exposure for iDSecure administrative interfaces and allow access only from trusted administrative networks.
• Search historical application, web, proxy, WAF, and authentication logs for passwordCustom usage, abnormal administrator logins, and administrative activity without expected preceding authentication events.
• Review all administrator accounts, recently created users, access-control policy changes, device enrollment changes, and configuration exports for signs of unauthorized activity.
• Rotate privileged credentials, API keys, and integration secrets after patching if exploitation cannot be confidently ruled out.
• Add SIEM and WAF detections for requests containing passwordCustom and for anomalous successful administrative logins from new IP addresses, geographies, user agents, or impossible-travel patterns.
• If Debian package tracking applies, update Debian 12 systems to 6.1.90-1 or later and Debian 13 systems to 6.8.9-1 or later.