You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@superset.apache.org by "bsethi24 (via GitHub)" <gi...@apache.org> on 2026/09/30 12:34:44 UTC

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

GitHub user bsethi24 created a discussion: Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?

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 vulnerabilties) 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.

GitHub link: https://github.com/apache/superset/discussions/44823

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org

Re: [D] Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache? [superset]

Posted by "bhargavmehta01 (via GitHub)" <gi...@apache.org>.

GitHub user bhargavmehta01 added a comment to the discussion: Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?

@bsethi24 Good news on the CVE: CVE-2021-33026 doesn't cover the Flask-Caching 2.x line, so it shouldn't be what's blocking your 6.1.0 build.

- **Affected range.** The GitHub advisory [GHSA-656c-6cxf-hvcv](https://github.com/advisories/GHSA-656c-6cxf-hvcv) lists the affected versions as `<= 1.10.1`. NVD's CPE configuration also ends at `versionEndIncluding: 1.10.1`. Superset 6.1.0 requires `flask-caching>=2.1.0, <3` and pins `2.3.1`, so none of the versions blocked in your mirror (2.0.2 to 2.5.1) is in either record's range. A scanner that flags them is matching on the package name, not the version. That's a false positive you can take back to your security team or mirror vendor with those two links.
- **Severity.** The 9.8 is NVD's score. GitHub rates the advisory *Moderate*, and the CVE is tagged **disputed**. The maintainers' position is that an attack needs write access to the cache storage plus a colliding cache key. Anyone with that access already controls what the app serves.
- **Your config.** `NullCache` stores nothing, so there's nothing to deserialize. For the two `SupersetMetastoreCache` configs, keep `"CODEC": JsonKeyValueCodec()` in your overrides. That's the 6.1.0 default in `config.py`, but `SupersetMetastoreCache.factory` falls back to `PickleKeyValueCodec` when `CODEC` is missing, and logs "Using PickleKeyValueCodec with SupersetMetastoreCache may be unsafe". With JSON there's no pickle anywhere in the runtime you described.

```python
from superset.key_value.types import JsonKeyValueCodec

FILTER_STATE_CACHE_CONFIG = {
    "CACHE_TYPE": "SupersetMetastoreCache",
    "CACHE_DEFAULT_TIMEOUT": 7776000,
    "REFRESH_TIMEOUT_ON_RETRIEVAL": True,
    "CODEC": JsonKeyValueCodec(),
}
EXPLORE_FORM_DATA_CACHE_CONFIG = {
    "CACHE_TYPE": "SupersetMetastoreCache",
    "CACHE_DEFAULT_TIMEOUT": 7776000,
    "REFRESH_TIMEOUT_ON_RETRIEVAL": True,
    "CODEC": JsonKeyValueCodec(),
}
```

- **Remediation path.** Allowlist `flask-caching==2.3.1`, the version 6.1.0 pins and tests against. Record the exception against the advisory's `<= 1.10.1` range. Neither record lists a 2.x release as affected, so there's no "fixed" release to wait for. Removing the package isn't an option, as @dfbustosus explained above.
- **If you add Redis later,** the CVE's precondition is write access to the cache store, so lock that down: a private network endpoint, `requirepass` or ACLs with the secret pulled from your secret manager, and TLS (`rediss://`).

How I checked: the OSV/GitHub advisory record and the NVD API record for CVE-2021-33026, plus `pyproject.toml`, `requirements/base.txt`, `superset/config.py` and `superset/extensions/metastore_cache.py` at the `6.1.0` tag.

GitHub link: https://github.com/apache/superset/discussions/44823#discussioncomment-18873416

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org

Re: [D] Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache? [superset]

Posted by "dfbustosus (via GitHub)" <gi...@apache.org>.

GitHub user dfbustosus added a comment to the discussion: Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?

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`](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/pyproject.toml#L39-L56), and the generated 6.1.0 requirements pin [`flask-caching==2.3.1`](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/requirements/base.txt#L120-L132).

It is also required by the implementation:

- [`SupersetCache` subclasses `flask_caching.Cache`](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/superset/utils/cache_manager.py#L20-L26).
- [`CacheManager` constructs and initializes those cache objects](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/superset/utils/cache_manager.py#L186-L237).
- [`SupersetMetastoreCache` subclasses `flask_caching.BaseCache`](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/superset/extensions/metastore_cache.py#L20-L42).

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](https://github.com/apache/superset/blob/c83fb2bb1dcfac41ac51bcebd82471f4a7180d18/docs/versioned_docs/version-6.0.0/configuration/cache.mdx#L8-L52).

GitHub link: https://github.com/apache/superset/discussions/44823#discussioncomment-18687296

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org

Re: [D] Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache? [superset]

Posted by "bsethi24 (via GitHub)" <gi...@apache.org>.

GitHub user bsethi24 added a comment to the discussion: Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?

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.

GitHub link: https://github.com/apache/superset/discussions/44823#discussioncomment-18758365

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org

Re: [D] Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache? [superset]

Posted by "bsethi24 (via GitHub)" <gi...@apache.org>.

GitHub user bsethi24 edited a discussion: Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?

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

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.

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.

GitHub link: https://github.com/apache/superset/discussions/44823

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org

Re: [D] Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache? [superset]

Posted by "FrancescoCastaldi (via GitHub)" <gi...@apache.org>.

GitHub user FrancescoCastaldi added a comment to the discussion: Superset 6.1: is flask-caching still structurally required when runtime uses NullCache and SupersetMetastoreCache?

To address your questions directly regarding Superset 6.1.0 dependency architecture:

### 1. Is `flask-caching` structurally required?
Yes. `flask-caching` is an integral architectural dependency of Apache Superset. Even when you configure `NullCache` or `SupersetMetastoreCache`:
- `SupersetCache` directly inherits from `flask_caching.Cache` (`superset/utils/cache_manager.py`).
- `SupersetMetastoreCache` inherits from `flask_caching.base.BaseCache` (`superset/extensions/metastore_cache.py`).
Removing `flask-caching` from the Python environment causes immediate `ModuleNotFoundError` exceptions during application startup (`superset/app.py`).

### 2. Security Assessment and False Positive Resolution (CVE-2021-33026)
The block in your private mirror for `flask-caching` 2.x releases based on CVE-2021-33026 is a scanner false positive:
- **Official Range:** Both the GitHub Advisory Database (GHSA-656c-6cxf-hvcv) and the National Vulnerability Database (NVD) specify that CVE-2021-33026 affects only versions `<= 1.10.1`.
- **Superset 6.1.0 Pin:** Superset 6.1.0 pins `flask-caching==2.3.1`, which is completely outside the affected version range.
- **Deserialization Safety:** To eliminate pickle deserialization risks entirely, ensure your `SupersetMetastoreCache` configurations explicitly specify `JsonKeyValueCodec`:
```python
from superset.key_value.types import JsonKeyValueCodec

FILTER_STATE_CACHE_CONFIG = {
    "CACHE_TYPE": "SupersetMetastoreCache",
    "CACHE_DEFAULT_TIMEOUT": 7776000,
    "REFRESH_TIMEOUT_ON_RETRIEVAL": True,
    "CODEC": JsonKeyValueCodec(),
}
EXPLORE_FORM_DATA_CACHE_CONFIG = {
    "CACHE_TYPE": "SupersetMetastoreCache",
    "CACHE_DEFAULT_TIMEOUT": 7776000,
    "REFRESH_TIMEOUT_ON_RETRIEVAL": True,
    "CODEC": JsonKeyValueCodec(),
}
```

### 3. Recommended Remediation
Submit a security exception to your package mirror administrators referencing GHSA-656c-6cxf-hvcv to allowlist `flask-caching==2.3.1`. This allows the standard Superset 6.1.0 container build to complete cleanly without modifying the core caching architecture.


GitHub link: https://github.com/apache/superset/discussions/44823#discussioncomment-19164451

----
This is an automatically sent email for notifications@superset.apache.org.
To unsubscribe, please send an email to: notifications-unsubscribe@superset.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org