The jQuery Cookie plugin (jquery.cookie) is deprecated, no longer maintained, and carries a known prototype-pollution vulnerability, so you should replace it with the actively maintained js-cookie library. For years jquery.cookie was the default way to read and write browser cookies in jQuery-heavy front ends, and it still lingers in legacy themes, plugins, and vendored scripts. If a dependency scan flagged it, or you found it in a jquery cookie cdn reference inside an old page, this is the context you need.
The plugin was renamed and eventually superseded, and understanding that lineage explains why you keep seeing three different names for what looks like the same thing.
The naming history in one paragraph
The original project was jquery.cookie, a small plugin that added $.cookie() to jQuery. Its author later rewrote it as a standalone library with no jQuery dependency, called js-cookie. So jquery.cookie is the old, jQuery-coupled, abandoned version, and js-cookie is its modern, framework-independent successor. When you see a jquery cookie cdn link pointing at a 1.4.x file, that is the old plugin, and it should not be added to new projects.
The vulnerability: CVE-2022-23395
The specific security problem with the last release, version 1.4.1, is CVE-2022-23395: prototype pollution that can lead to DOM cross-site scripting.
The mechanism is a classic prototype-pollution bug. When the plugin parses cookie names and values into a JavaScript object, it does not guard against special property keys like __proto__. A cookie crafted to carry such a key can write to Object.prototype, which is shared by every object in the page. Once the prototype is polluted, code elsewhere that reads a property it expects to be undefined may instead read the attacker's injected value, and in the wrong sink that becomes DOM XSS.
Because the value can originate from a cookie, and cookies can sometimes be influenced across subdomains or by a compromised adjacent application, this is not purely theoretical for multi-app environments sharing a domain.
The practical point: there is no patched release of jquery.cookie that fixes this. The project is not in development. The remediation is replacement, not upgrade.
Migrating to js-cookie
The good news is that js-cookie has a nearly identical mental model, so the migration is mostly find-and-replace plus dropping the jQuery coupling.
Install it:
npm install js-cookie
Old jquery.cookie code:
// jquery.cookie (deprecated)
$.cookie('theme', 'dark', { expires: 7, path: '/' });
var theme = $.cookie('theme');
$.removeCookie('theme', { path: '/' });
Equivalent js-cookie:
import Cookies from 'js-cookie';
Cookies.set('theme', 'dark', { expires: 7, path: '/' });
const theme = Cookies.get('theme');
Cookies.remove('theme', { path: '/' });
The API shape barely changed, but the modern library drops the jQuery dependency entirely, encodes and decodes values safely by default, and is actively maintained. For a straight browser include there is a UMD build you can vendor locally rather than pulling from a third-party CDN, which is the safer choice for a security-sensitive page.
Set cookies securely while you are in there
A migration is a good moment to fix the attributes, because the plugin's defaults predate modern cookie hardening. When you write cookies from JavaScript, set the security attributes explicitly:
Cookies.set('session_hint', value, {
expires: 1,
path: '/',
secure: true, // HTTPS only
sameSite: 'strict', // no cross-site sending
});
One caveat worth stating plainly: the HttpOnly attribute cannot be set from JavaScript at all, because its entire purpose is to hide the cookie from scripts. Any genuinely sensitive cookie, such as a real session token, should be set by the server with HttpOnly and never touched by a client-side cookie library. Client-side cookie helpers are for non-sensitive UI state.
A note on newer prototype-pollution findings
Prototype pollution is a recurring theme in cookie handling, not a one-time bug in one old plugin. Even the modern js-cookie line has seen advisories in its internal helpers over time, which is a reminder that "use the maintained library" means "and keep it updated," not "and forget about it." Pin a version, watch its advisory feed, and let dependency scanning tell you when a new one lands. An SCA tool such as Safeguard can flag a vulnerable jquery.cookie even when it is buried inside a bundled theme, which is usually how teams find they still ship it. The SCA product page describes how that transitive detection works, and our academy covers front-end dependency hygiene.
Finding jquery.cookie in your codebase
Because the file is often vendored rather than installed through a package manager, a grep for the telltale API is more reliable than checking package.json:
grep -rn "jquery.cookie\|\$\.cookie\|\$\.removeCookie" ./src ./public
Check bundled vendor directories, WordPress theme folders, and any minified all.js-style concatenations, which are the usual hiding spots.
FAQ
Is jquery.cookie safe to use in 2026?
No. The plugin is deprecated, unmaintained, and its last release (1.4.1) is affected by CVE-2022-23395 prototype pollution with no fixed version available. Replace it with js-cookie.
What is the difference between jquery.cookie and js-cookie?
They come from the same author. jquery.cookie is the original jQuery-dependent plugin, now abandoned. js-cookie is the rewritten, framework-independent, actively maintained successor with a nearly identical API and safer defaults.
How do I migrate from jquery.cookie to js-cookie?
Install js-cookie, then swap $.cookie(name, value, opts) for Cookies.set(name, value, opts), $.cookie(name) for Cookies.get(name), and $.removeCookie(name, opts) for Cookies.remove(name, opts). The options object is largely compatible, and while migrating you should add secure and sameSite attributes.
Can I just patch jquery.cookie instead of replacing it?
There is no official patched release, since the project is no longer in development. Maintaining a private fork is far more work than the near-drop-in migration to js-cookie, so replacement is the recommended path.