Loophole-LLC/Bastillion v6.0.1

6.0.1

on GitHub

Security

• High: SAML/LDAP login could sign in as a different user. AuthDB.getUserByUID matched the SAML NameID or LDAP login name with lower(username) like lower(?), so % and _ in it acted as wildcards, and when several accounts matched, the last row won. An IdP identity such as john_smith@corp.com signed in as john.smith@corp.com, up to Full Access. Logging in also rotated the victim's auth token, logging them out, cleared their local password, and on SAML rewrote their profile membership from the attacker's role claims. The lookup is now an exact case-insensitive match, and a login that matches more than one account is refused. UserDB.isUnique had the same LIKE and wrongly reported usernames containing _ as taken; it now matches exactly too. Reported by @a25370 (GHSA-5qgc-52c7-26mg).

Changed

• The README now recommends locking down the default admin account: change its password, require two-factor, and delete it on LDAP/SAML deployments once a directory user has Full Access, since an external identity named exactly admin would sign in as it.

Dependencies

• com.github.mwiede:jsch 2.28.7 → 2.28.8
• org.apache.mina:mina-core 2.2.9 → 2.2.10
• commons-codec:commons-codec 1.22.1 → 1.23.0
• github/codeql-action 4.38.2 → 4.39.0

Upgrade notes:

• Upgrade promptly if you use SAML or LDAP login; local-only installs are not affected by the login issue. No config or schema changes. A local account that was matched this way had its password cleared, so a user whose local password suddenly stopped working is worth checking.

• If upgrading from 5.2.x: the new tables and columns are created on first start and need no action — upgrading from 5.2.x has been tested end to end. Host key verification defaults to accept-new, so existing systems keep connecting and their keys are recorded as they are first seen; set hostKeyVerification=strict to require approval instead, or off to keep the pre-6.0.0 behavior. The certificate authority is off until sshCertificateAuth is set. keyManagementEnabled=true/false is still honored and maps to manage/append.

Upgrading from v4? v4 kept its H2 database inside the Jetty webapp, encrypted with that install's keystore, so 6.x cannot read it in place. Use the migration tool — you do not need to install 5.x first, you can import straight into 6.0.1:

# 1. export from the old v4 install (its WEB-INF/classes is the config dir)
./migrate.sh export /opt/Bastillion-jetty/jetty/bastillion/WEB-INF/classes/ ~/export.json

# 2. start 6.0.1 once against the new config dir, then stop it - creates schema + keystore
java -DCONFIG_DIR=/data/bastillion/ -jar bastillion-6.0.1.jar

# 3. import
./migrate.sh import /data/bastillion/ ~/export.json --yes-replace-all-data

# 4. the export holds plaintext secrets - delete it
rm ~/export.json

Users keep their existing passwords. Every column a v4 export carries still exists in the 6.0.0 schema, and the two columns 6.0.0 adds to those tables take their default or null. Full details in tools/migrate/README.md. bastillion-migrate-1.0.0.jar is attached to this release, and migrate.sh fetches it automatically, verifying its checksum.