opensearch-personalize-caching-strategies

Warn

Audited by Socket on Sep 16, 2026

4 alerts found:

Securityx3Anomaly
SecurityMEDIUM
references/pers-anonymous-vs-logged-split.md

The code appears to implement legitimate recommendation caching and contains no apparent malware or supply-chain attack behavior. However, the logged-in cache is incorrectly keyed only by cohort while storing per-user personalized results, which can expose one user's recommendations to other cohort members and should be corrected by using cohort-safe non-personalized data or including userId and enforcing appropriate cache isolation. Input normalization and JSON parse/error validation should also be added.

Confidence: 98%Severity: 72%
AnomalyLOW
references/strat-async-warm-up.md

The fragment describes a legitimate cache-warming design, not malware. However, the example has a significant availability and access-control weakness: an apparently unauthenticated, expensive /warmup endpoint can be repeatedly triggered, and Kubernetes probe retries may amplify the load. Restrict the route to an internal authenticated caller or lifecycle hook, make warm-up idempotent and single-flight, validate S3 and event inputs, bound all external work, and separate readiness signaling from an expensive HTTP probe.

Confidence: 97%Severity: 68%
SecurityMEDIUM
references/decide-search-vs-personalize-asymmetry.md

No malicious behavior or supply-chain malware is evident. The recommendation example has a potentially critical privacy and correctness flaw: user-specific Personalize results are cached by cohort and may be returned to other users in that cohort. Use a user-specific key for user-personalized results, or ensure the personalization request and output are explicitly cohort-level before sharing the cache entry. The remainder is ordinary caching guidance.

Confidence: 96%Severity: 72%
SecurityMEDIUM
references/key-segment-not-user.md

The fragment is not evidently malicious, but the principal implementation is insecure and logically incorrect for individualized recommendations: user-specific Personalize output is stored under a shared cohort key and can be returned to unrelated users. This can cause privacy leakage, personalization errors, and cross-user data exposure. The example should cache cohort-level data only, or perform per-user reranking after retrieving a cohort candidate set. The unspecified assignCohort implementation requires separate review.

Confidence: 98%Severity: 72%
Audit Metadata
Analyzed At
Sep 16, 2026, 10:52 AM
Package URL
pkg:socket/skills-sh/pproenca%2Fdot-skills%2Fopensearch-personalize-caching-strategies%2F@def3aad49e3ea8d91cae9c9c7536f456022a33c8a215ec60a0ff0a8bef97a415
Security Audit — socket — opensearch-personalize-caching-strategies