The vulnerability in OpenTofu versions 1.8.0 through 1.8.2 stems from a fundamental mismatch: the 'sensitive' flag was designed as a UI-layer annotation to mask values in plan and apply output, not as a data classification mechanism that constrains all evaluation paths. When version 1.8.0 introduced configurable static evaluation for module sources, backends, and version constraints, it created an evaluation context that runs before the runtime phase where sensitive flags are normally respected. Developers who correctly marked variables as sensitive were operating under false assurance—their values could still propagate into module resolution, backend configuration, and dependency constraints during the static phase.
The fix in version 1.8.3 addresses this by throwing explicit errors when sensitive values are encountered in static evaluation contexts. This is the correct immediate response, but it introduces real tradeoffs. Organizations relying on dynamic module registries with authenticated endpoints, backend configurations derived from sensitive inputs, or version constraints computed from secret values will need to refactor workflows. These aren't exotic edge cases; they're common patterns in mature infrastructure codebases.
Your priorities: upgrade to 1.8.3 immediately—this closes the active exposure. Then audit your module sources, backend configurations, and any expressions referencing sensitive variables for static resolution. If your workflows depended on this behavior, you'll need non-sensitive proxy values or restructured configurations. Be aware that this fix addresses one specific leakage path; the broader architectural question of what 'sensitive' means across all evaluation contexts remains unresolved. Future versions may introduce additional evaluation surfaces where similar gaps could reopen.