This problem occurs when database credentials and Vault macros are stored in multiple HashiCorp KV v2 secret engines.

Example:

Database credentials:

kv-database/zabbix/aws/test

Macro secrets:

kv-database/servicenow/api/user

kv-team-two/local/secret/api

With VaultPrefix unset, macro paths work correctly because Zabbix inserts /v1/<engine>/data/ automatically.

However, since 7.0.31, the container entrypoint builds the database credentials URL incorrectly:

Actual:

/v1/kv-database/zabbix/aws/data/test

Expected:

/v1/kv-database/data/zabbix/aws/test

Using a mount-specific prefix fixes the database path but prevents access to macros in other secret engines.

Using VaultPrefix=/v1/ allows access to multiple engines, but then /data/ must be added manually to VaultDBPath and every existing macro path.

The entrypoint should treat the first component of VaultDBPath as the secret engine, consistently with the runtime Vault macro implementation. This would allow VaultPrefix to remain unset and support multiple secret engines without changing existing macros.

The issue is present in the 7.0.31 and 7.0.32 Alpine MySQL images.