Until the first signed public release is published, only the current default branch is maintained. After publication, the latest signed minor release receives security fixes. Older releases may be unsupported; upgrade to the latest verified archive before reporting a reproducibility problem.
Do not open a public issue for a suspected vulnerability or secret exposure. After this repository is public and GitHub private vulnerability reporting is enabled, use the repository's private reporting route:
https://github.com/veritrans/midtrans-cli/security/advisories/new
Until that route is enabled, use Midtrans's official vulnerability disclosure channel documented at https://docs.midtrans.com/docs/payment-security.
Include affected versions and safe reproduction steps. Never include a usable Midtrans credential, complete provider payload, cardholder data, or merchant customer data.
- v0.1 resolves credentials only from process-environment references or owner-only project-relative files declared in the manifest. It does not persist resolved values.
- Secret values and configured sensitive keys are structurally redacted before result or evidence output.
- Network policy permits only the Sandbox hosts compiled into each product pack. Production Midtrans hosts are prohibited.
- Evidence is created with owner-only permissions and validated before use.
Production-key testing is prohibited, even for a harmless-looking command. The
CLI validates the SB- prefix for classic server keys, but BI-SNAP credentials
cannot be classified by format. Operators must confirm they supplied Sandbox
BI-SNAP credentials. If there is doubt about any key, rotate it and obtain a
dedicated Sandbox credential before continuing.
Use midtrans evidence export to create a structurally redacted copy plus
SHA256SUMS. Inspect the exported JSON again before sharing it. Share the
minimum necessary file through an approved private support channel; do not
paste evidence into a public issue or chat. Order IDs and provider transaction
IDs are intentionally treated as safe references, but merchants should still
replace them when their internal policy classifies those identifiers as
sensitive.