Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?

[bsethi24]

We are deploying Apache Superset 6.1.0 and validated the live runtime behavior.

Current runtime:

• CACHE CONFIG- NullCache
• DATA CACHE CONFIG = NullCache
• FILTER STATE CACHE CONFIG = SupersetMetastoreCache
• EXPLORE FORM DATA CACHE CONFIG = SupersetMetastoreCache
• RESULTS BACKEND = None
• no Redis configured
• no Memcached configured

So the current deployment is not using an external shared cache backend.

However, Superset 6.1 still appears to require flask-caching in the dependency set. We want to confirm whether this is still expected even when runtime uses only NullCache and SupersetMetastoreCache.

We observed Flask-Caching versions blocked in our mirror with 403 (quarantined due to vulnerabilities) for multiple Flask-Caching 2.x releases, which is why we are trying to understand whether the dependency is structurally required or whether there is any supported way to avoid it. As its blocker for Superset 6.1.0 image creation.

Questions:

1. Is flask-caching still an expected dependency for Superset 6.1 in this runtime model?
2. Is SupersetMetastoreCache still implemented through Flask-Caching abstractions?
3. Is there any supported way to avoid this dependency while staying on Superset 6.17
4. If Redis or Memcached is needed later for scale or distributed coordination, what is the recommended secure configuration pattern?

Blocked versions observed in our mirror path:
2.5.1
2.5.0
2.4.1
2.4.0
2.3.1
2.3.0
2.2.0
2.1.0
2.0.2

We are trying to separate
1 current runtime behavior
2. dependency/build behavior
3. future Redis/Memcached use cases
4.

[dfbustosus]

Assuming "6.17" means Superset 6.1.0: yes, flask-caching remains structurally required even when no external cache service is configured.

It is an unconditional runtime dependency in pyproject.toml, and the generated 6.1.0 requirements pin flask-caching==2.3.1.

It is also required by the implementation:

• SupersetCache subclasses flask_caching.Cache.
• CacheManager constructs and initializes those cache objects.
• SupersetMetastoreCache subclasses flask_caching.BaseCache.

Therefore, NullCache means "use a no-op runtime backend"; it does not bypass the Flask-Caching extension. SupersetMetastoreCache is likewise a custom Flask-Caching backend, not a replacement for that package.

There is no supported configuration-only way to remove the dependency while staying on 6.1.0. Installing with --no-deps or deleting it leaves imports unresolved during startup. The supported options are to have the quarantined 2.3.1 release reviewed and allowed through your mirror, use another approved mirror, or maintain a downstream fork replacing Superset's caching integration.

Redis or Memcached is not required for the runtime configuration shown. For a future multi-instance deployment, Redis is the documented general choice: use a private endpoint, authentication supplied through a secret manager, TLS where supported, distinct key prefixes/logical databases, and appropriate HA. Keep Flask-Caching backends, Celery broker/results, and distributed coordination as separately configured concerns. Memcached can support general Flask-Caching use, but cannot replace Redis-specific coordination.

Current cache configuration and recommendations are documented here.

[bsethi24]

Hi @dfbustosus / Team...... Thanks for the response.

Our main concern is the current Flask-Caching package version in our build: 2.3.1 (and the broader 2.x line, including 2.5.1), which is flagged by our security scan as a Critical issue (CVE-2021-33026, score 9.8).

• We would like to understand the supported remediation path for Superset 6.1 users who are blocked by mirror or policy constraints

1. Is there a recommended upgrade path to a non-vulnerable version?

2. Is there any supported way to avoid the dependency when only NullCache or melastore-backed cache modes are used?

3. If no supported removal path exists, what is the recommended remediation plan for a production build that cannot consume the vulnerable version?

4. Is this CVE expected to be fixed in a newer supported release?

Please advise on the recommended approach and any guidance available from the maintainers.