CWE-613
Allowed-with-ReviewInsufficient Session Expiration
Abstraction: Base · Status: Incomplete
According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."
1083 vulnerabilities reference this CWE, most recent first.
GHSA-H7VV-46P5-PRMH
Vulnerability from github – Published: 2023-04-05 18:30 – Updated: 2023-04-05 21:28Firefly III prior to 6.0.0 insufficiently expires sessions upon close.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "grumpydictator/firefly-iii"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-1788"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-05T21:28:05Z",
"nvd_published_at": "2023-04-05T16:15:00Z",
"severity": "MODERATE"
},
"details": "Firefly III prior to 6.0.0 insufficiently expires sessions upon close.",
"id": "GHSA-h7vv-46p5-prmh",
"modified": "2023-04-05T21:28:05Z",
"published": "2023-04-05T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1788"
},
{
"type": "WEB",
"url": "https://github.com/firefly-iii/firefly-iii/commit/68f398f97cbe1870fc098d8460bf903b9c3fab30"
},
{
"type": "WEB",
"url": "https://github.com/firefly-iii/firefly-iii"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/79323c9e-e0e5-48ef-bd19-d0b09587ccb2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Firefly III insufficiently expires sessions"
}
GHSA-H8Q5-VXRG-QGMF
Vulnerability from github – Published: 2026-04-22 18:31 – Updated: 2026-04-22 18:31GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 18.9.6, 18.10 before 18.10.4, and 18.11 before 18.11.1 that could have allowed a user to use invalidated or incorrectly scoped credentials to access Virtual Registries under certain conditions.
{
"affected": [],
"aliases": [
"CVE-2026-6515"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T17:16:44Z",
"severity": "MODERATE"
},
"details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.2 before 18.9.6, 18.10 before 18.10.4, and 18.11 before 18.11.1 that could have allowed a user to use invalidated or incorrectly scoped credentials to access Virtual Registries under certain conditions.",
"id": "GHSA-h8q5-vxrg-qgmf",
"modified": "2026-04-22T18:31:46Z",
"published": "2026-04-22T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6515"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/04/22/patch-release-gitlab-18-11-1-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/595993"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-H998-HXXJ-8Q83
Vulnerability from github – Published: 2026-06-22 15:30 – Updated: 2026-09-15 19:51Mattermost versions 11.7.x <= 11.7.0, 11.6.x <= 11.6.2, 11.5.x <= 11.5.5, 10.11.x <= 10.11.17 fail to invalidate cached authentication state for active WebSocket connections during global session revocation, which allows a user with an existing WebSocket connection to remain authenticated and continue receiving real-time events until the cached session expires or the client reconnects.. Mattermost Advisory ID: MMSA-2026-00664
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.7.0"
},
{
"fixed": "11.7.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.6.0"
},
{
"fixed": "11.6.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "11.5.0"
},
{
"fixed": "11.5.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.11.0"
},
{
"fixed": "10.11.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9162"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-15T19:51:33Z",
"nvd_published_at": "2026-06-22T14:17:55Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 11.7.x \u003c= 11.7.0, 11.6.x \u003c= 11.6.2, 11.5.x \u003c= 11.5.5, 10.11.x \u003c= 10.11.17 fail to invalidate cached authentication state for active WebSocket connections during global session revocation, which allows a user with an existing WebSocket connection to remain authenticated and continue receiving real-time events until the cached session expires or the client reconnects.. Mattermost Advisory ID: MMSA-2026-00664",
"id": "GHSA-h998-hxxj-8q83",
"modified": "2026-09-15T19:51:33Z",
"published": "2026-06-22T15:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9162"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Mattermost doesn\u0027t invalidate cached authentication state for active WebSocket connections during global session revocation"
}
GHSA-H9Q8-5GV2-V6MG
Vulnerability from github – Published: 2021-03-12 23:09 – Updated: 2026-02-02 21:01Impact
Potential session hijacking of store customers.
Patches
We recommend to update to the current version 6.3.5.2. You can get the update to 6.3.5.2 regularly via the Auto-Updater or directly via the download overview.
https://www.shopware.com/en/download/#shopware-6
Workarounds
For older versions of 6.1 and 6.2, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
https://store.shopware.com/en/detail/index/sArticle/518463/number/Swag136939272659
For more information
https://docs.shopware.com/en/shopware-6-en/security-updates/security-update-03-2021
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.3.5.1"
},
"package": {
"ecosystem": "Packagist",
"name": "shopware/platform"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.3.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-32710"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-12T22:10:34Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nPotential session hijacking of store customers.\n\n### Patches\nWe recommend to update to the current version 6.3.5.2. You can get the update to 6.3.5.2 regularly via the Auto-Updater or directly via the download overview.\n\nhttps://www.shopware.com/en/download/#shopware-6\n\n### Workarounds\nFor older versions of 6.1 and 6.2, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.\n\nhttps://store.shopware.com/en/detail/index/sArticle/518463/number/Swag136939272659\n\n### For more information\nhttps://docs.shopware.com/en/shopware-6-en/security-updates/security-update-03-2021",
"id": "GHSA-h9q8-5gv2-v6mg",
"modified": "2026-02-02T21:01:07Z",
"published": "2021-03-12T23:09:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shopware/platform/security/advisories/GHSA-h9q8-5gv2-v6mg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32710"
},
{
"type": "WEB",
"url": "https://github.com/shopware/platform/commit/010c0154bea57c1fca73277c7431d029db7a972e"
},
{
"type": "PACKAGE",
"url": "https://github.com/shopware/shopware"
},
{
"type": "WEB",
"url": "https://packagist.org/packages/shopware/platform"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Potential Session Hijacking"
}
GHSA-HGJ5-8XCV-G949
Vulnerability from github – Published: 2026-09-23 09:30 – Updated: 2026-09-23 09:30A session management vulnerability exists in the Legacy UI Reduced Function Login feature of NT-ware uniFLOW Online. Under specific timing conditions during Service Offline Emergency Mode, a previously authenticated session may be retained after logout, which could allow a subsequent user to be authenticated as the previous user and gain unauthorised limited access to device functionality.
{
"affected": [],
"aliases": [
"CVE-2026-92378"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-23T08:17:14Z",
"severity": "MODERATE"
},
"details": "A session management\nvulnerability exists in the Legacy UI Reduced Function Login feature of NT-ware\nuniFLOW Online. Under specific timing conditions during Service Offline\nEmergency Mode, a previously authenticated session may be retained after\nlogout, which could allow a subsequent user to be authenticated as the previous\nuser and gain unauthorised limited access to device functionality.",
"id": "GHSA-hgj5-8xcv-g949",
"modified": "2026-09-23T09:30:31Z",
"published": "2026-09-23T09:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92378"
},
{
"type": "WEB",
"url": "https://ntware.atlassian.net/wiki/spaces/SA/pages/14160592897/Security+Advisory+Previous+login+session+retained+when+entering+Reduced+Function+Login"
},
{
"type": "WEB",
"url": "https://www.canon-europe.com/psirt/advisory-information"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:P/AC:L/AT:P/PR:L/UI:P/VC:N/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"
}
]
}
GHSA-HGX3-J7FM-PJM3
Vulnerability from github – Published: 2025-12-01 18:30 – Updated: 2025-12-01 21:30nopCommerce v4.70 and prior, and version 4.80.3, does not invalidate session cookies after logout or session termination, allowing an attacker who has a a valid session cookie access to privileged endpoints (such as /admin) even after the legitimate user has logged out, enabling session hijacking. Any version above 4.70 that is not 4.80.3 fixes the vulnerability.
{
"affected": [],
"aliases": [
"CVE-2025-11699"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-01T16:15:51Z",
"severity": "HIGH"
},
"details": "nopCommerce v4.70 and prior, and version 4.80.3, does not invalidate session cookies after logout or session termination, allowing an attacker who has a \na valid session cookie access to privileged endpoints (such as /admin) even after the legitimate user has logged out, enabling session hijacking. Any version above 4.70 that is not 4.80.3 fixes the vulnerability.",
"id": "GHSA-hgx3-j7fm-pjm3",
"modified": "2025-12-01T21:30:26Z",
"published": "2025-12-01T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11699"
},
{
"type": "WEB",
"url": "https://github.com/nopSolutions/nopCommerce/issues/7044"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2025/Aug/14"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/633103"
},
{
"type": "WEB",
"url": "https://www.nopcommerce.com/en/release-notes?srsltid=AfmBOoravPKjN19pm_XZbXZ7GvPhkt8cxlK6794BJRZlY5RxJU_yNoTT"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HJC2-P4MC-RCPR
Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31A vulnerability exists in SenseLive
X3050’s web management interface due to improper session lifetime enforcement, allowing authenticated sessions to remain active for extended periods without requiring re-authentication. An attacker with access to a previously authenticated session could continue interacting with administrative functions long after legitimate user activity has ceased.
{
"affected": [],
"aliases": [
"CVE-2026-25720"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T00:16:26Z",
"severity": "MODERATE"
},
"details": "A vulnerability exists in\u00a0SenseLive\n\nX3050\u2019s web management interface due to improper session lifetime enforcement, allowing authenticated sessions to remain active for extended periods without requiring re-authentication. An attacker with access to a previously authenticated session could continue interacting with administrative functions long after legitimate user activity has ceased.",
"id": "GHSA-hjc2-p4mc-rcpr",
"modified": "2026-04-24T00:31:52Z",
"published": "2026-04-24T00:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25720"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-111-12.json"
},
{
"type": "WEB",
"url": "https://senselive.io/contact"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-111-12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/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"
}
]
}
GHSA-HJX8-QV73-F7CM
Vulnerability from github – Published: 2026-10-09 20:57 – Updated: 2026-10-09 20:57Summary
A collaborator removed from a project keeps a live, automatic feed of that project's contents, because nothing on any revocation path deletes the webhook they created while they had access.
Vikunja already has a revocation-cleanup routine that deletes other derived rows for exactly this reason. Its set is {task_assignees, subscriptions}. webhooks and link_shares — the only two rows that carry a live channel into the project — are not in it, and the routine is wired to one of four revocation paths.
Details
pkg/models/teams.go:411 — cleanupTaskMembersAfterTeamRemoval, added in 9358954c9, whose commit message states the invariant: "cleanup team memberships, assignments and subscriptions when users lose access to a project".
canRead, _, permErr := project.CanRead(s, &user.User{ID: memberID})
...
if !canRead {
projectsToCleanup = append(projectsToCleanup, projectID)
}
...
_, err = s.In("task_id", taskIDs).And("user_id = ?", memberID).
Delete(&TaskAssginee{})
_, err = s.In("entity_id", taskIDs).
Where("entity_type = ? AND user_id = ?", SubscriptionEntityTask, memberID).
Delete(&Subscription{})
_, err = s.In("entity_id", projectsToCleanup).
Where("entity_type = ? AND user_id = ?", SubscriptionEntityProject, memberID).
Delete(&Subscription{})
So you have already decided that losing read access must delete rows the departing user left behind, and that the test is a live project.CanRead. The gap is which rows are in the set.
And there is a second level, which is the sharper one. That routine has exactly one caller:
pkg/models/listeners.go:1642 err = cleanupTaskMembersAfterTeamRemoval(s, event.Team.ID, event.Member.ID)
against four revocation paths:
pkg/models/project_team.go:151 TeamProject.Delete
pkg/models/project_users.go:141 ProjectUser.Delete <- grep -c cleanup inside: 0
pkg/models/project_users.go:248 ProjectUser.Update <- the downgrade path
pkg/models/team_members.go:91 TeamMember.Delete <- the only one wired up
Removing a user directly from a project — the ordinary operation — dispatches nothing at all.
PoC
Released vikunja/vikunja:2.6.0 Docker image.
The harness was proved first by reproducing a known-fixed advisory: GHSA-qfwc refuses the read-only member and returns the hash to the owner. Every run carries its own negative control.
The strongest form is on the team-removal path, where your cleanup routine does fire:
== OWNER removes collab from the TEAM ==
-- did the cleanup routine run? --
assignees now: [] <- POSITIVE CONTROL: it ran
collab direct read of task: HTTP 403 <- NEGATIVE CONTROL: access is gone
-- webhook still delivering? --
WEBHOOK RECEIVED task_title='post-team-removal secret'
task_desc='cleanup ran, webhook did not'
-- link share still redeemable? --
[{"title":"post-team-removal secret","description":"cleanup ran, webhook did not"}]
The two controls are the argument: your own routine executed and removed the assignee rows, and the collaborator's direct read is refused with 403 — and the webhook created before removal still delivers the contents of a task created after it.
On the ProjectUser.Delete path the same thing happens with no cleanup running at all.
One lab accommodation, stated plainly: non-routable outbound IPs were enabled so a loopback sink was reachable. In a default deployment an attacker simply uses a public URL, so this changes nothing about reachability.
Impact
A former collaborator receives task titles and descriptions for the whole project, continuously, after their access has been revoked — including content created after revocation.
The honest counter-argument, which we would rather state than have you find. Both artefacts stay visible and auditable to the owner afterwards: GET /projects/{p}/webhooks still shows {"created_by":"collab"} and GET /projects/{p}/shares still shows {"shared_by":"collab"}. An administrator reviewing project settings after an offboarding will find them. That is genuinely weaker than a silent channel, and it argues for the low end of Medium.
The precondition is also real: the attacker held write access, so they could have taken a snapshot before leaving. The only thing new here is access to content created after revocation — which is precisely the line you drew yourselves in GHSA-jp29-jrxc-92vf, "favourites readable after revocation". We think it holds. It is also the entirety of the claim, and we are not dressing it up as more.
Affected range
All releases from v0.22.0 through v2.6.0, and current main.
Determined by checking the code at each released tag:
v0.22.0 … v0.24.6 webhooks.go=yes cleanupRoutine=0
v1.0.0 … v2.6.0 webhooks.go=yes cleanupRoutine=1
Project webhooks arrive in ad7d485eb (2023-10-17), first released in v0.22.0. The cleanup routine arrives in 9358954c9 (2025-10-09), first released in v1.0.0, and has never included webhooks or link shares. Still present on main at d822e1c58: the routine contains only Delete(&TaskAssginee{}) and two Delete(&Subscription{}), and ProjectUser.Delete contains zero dispatches.
Reproduced at v2.6.0; earlier versions asserted from source rather than run, and we are saying which is which.
Recommended Fix
Two changes, and they are independent — the first is the smaller one, the second is the one that closes the class.
Add the two row types to the cleanup set. Alongside the existing task_assignees and subscriptions deletions, delete webhooks and link_shares whose created_by / shared_by is the departing user and whose project is in projectsToCleanup. The existing live project.CanRead test is already the right predicate.
Dispatch the cleanup from all four revocation paths, not only team-member removal. ProjectUser.Delete and ProjectUser.Update (the downgrade case) are the common operations and currently fire nothing; TeamProject.Delete unshares a whole project from a team and is equally a revocation.
A cheaper alternative for the second half, if reworking dispatch is unattractive: check CanRead for the webhook's created_by at delivery time, and for the share's shared_by at redemption time. That converts a cleanup problem into an authorization check on a path that already has the user id to hand.
Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — 6.5 Medium.
This is the identical vector you assigned to your own webhook advisory, GHSA-7c2g-p23p-4jg3 (webhook BasicAuth credentials exposed to read-only members), copied rather than argued. PR:L because the attacker must have been provisioned with project write at some point; C:H because the channel carries full task titles and descriptions for the whole project continuously — the same C:H you assigned there for a credential leak of narrower scope.
The auditability caveat above argues for the low end of Medium and we would not contest a lower score.
The link share is strictly more capable, and we are not leading with it
The same gap leaves a link share created by the departing collaborator redeemable after revocation, and a link share carries read and write — HTTP 201 demonstrated. On the same reasoning that would be C:H/I:H = 8.1 High.
We are deliberately not proposing that, and leading with the webhook instead, because a link share has a real "it is designed to be handed out" defence and the webhook does not. That judgement is yours to make, and if you decide the share is the more serious half we will not argue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "code.vikunja.io/api"
},
"ranges": [
{
"events": [
{
"introduced": "0.22.0"
},
{
"last_affected": "2.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-613",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-09T20:57:41Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nA collaborator removed from a project keeps a **live, automatic feed** of that project\u0027s contents, because nothing on any revocation path deletes the webhook they created while they had access.\n\nVikunja already has a revocation-cleanup routine that deletes other derived rows for exactly this reason. Its set is `{task_assignees, subscriptions}`. **`webhooks` and `link_shares` \u2014 the only two rows that carry a live channel into the project \u2014 are not in it**, and the routine is wired to one of four revocation paths.\n\n## Details\n\n`pkg/models/teams.go:411` \u2014 `cleanupTaskMembersAfterTeamRemoval`, added in `9358954c9`, whose commit message states the invariant: *\"cleanup team memberships, assignments and subscriptions when users lose access to a project\"*.\n\n```go\n\t\tcanRead, _, permErr := project.CanRead(s, \u0026user.User{ID: memberID})\n\t\t...\n\t\tif !canRead {\n\t\t\tprojectsToCleanup = append(projectsToCleanup, projectID)\n\t\t}\n\t...\n\t\t_, err = s.In(\"task_id\", taskIDs).And(\"user_id = ?\", memberID).\n\t\t\tDelete(\u0026TaskAssginee{})\n\t\t_, err = s.In(\"entity_id\", taskIDs).\n\t\t\tWhere(\"entity_type = ? AND user_id = ?\", SubscriptionEntityTask, memberID).\n\t\t\tDelete(\u0026Subscription{})\n\t_, err = s.In(\"entity_id\", projectsToCleanup).\n\t\tWhere(\"entity_type = ? AND user_id = ?\", SubscriptionEntityProject, memberID).\n\t\tDelete(\u0026Subscription{})\n```\n\nSo you have already decided that losing read access must delete rows the departing user left behind, and that the test is a live `project.CanRead`. The gap is which rows are in the set.\n\n**And there is a second level, which is the sharper one.** That routine has exactly one caller:\n\n```\npkg/models/listeners.go:1642 err = cleanupTaskMembersAfterTeamRemoval(s, event.Team.ID, event.Member.ID)\n```\n\nagainst four revocation paths:\n\n```\npkg/models/project_team.go:151 TeamProject.Delete\npkg/models/project_users.go:141 ProjectUser.Delete \u003c- grep -c cleanup inside: 0\npkg/models/project_users.go:248 ProjectUser.Update \u003c- the downgrade path\npkg/models/team_members.go:91 TeamMember.Delete \u003c- the only one wired up\n```\n\nRemoving a user directly from a project \u2014 the ordinary operation \u2014 dispatches nothing at all.\n\n## PoC\n\nReleased `vikunja/vikunja:2.6.0` Docker image.\n\nThe harness was proved first by reproducing a **known-fixed** advisory: `GHSA-qfwc` refuses the read-only member and returns the hash to the owner. Every run carries its own negative control.\n\nThe strongest form is on the **team-removal path, where your cleanup routine does fire**:\n\n```\n== OWNER removes collab from the TEAM ==\n\n-- did the cleanup routine run? --\n assignees now: [] \u003c- POSITIVE CONTROL: it ran\n collab direct read of task: HTTP 403 \u003c- NEGATIVE CONTROL: access is gone\n\n-- webhook still delivering? --\nWEBHOOK RECEIVED task_title=\u0027post-team-removal secret\u0027\n task_desc=\u0027cleanup ran, webhook did not\u0027\n\n-- link share still redeemable? --\n[{\"title\":\"post-team-removal secret\",\"description\":\"cleanup ran, webhook did not\"}]\n```\n\nThe two controls are the argument: your own routine executed and removed the assignee rows, and the collaborator\u0027s direct read is refused with 403 \u2014 and the webhook created before removal still delivers the contents of a task created *after* it.\n\nOn the `ProjectUser.Delete` path the same thing happens with no cleanup running at all.\n\n**One lab accommodation, stated plainly**: non-routable outbound IPs were enabled so a loopback sink was reachable. In a default deployment an attacker simply uses a public URL, so this changes nothing about reachability.\n\n## Impact\n\nA former collaborator receives task titles and descriptions for the whole project, continuously, after their access has been revoked \u2014 including content created after revocation.\n\n**The honest counter-argument, which we would rather state than have you find.** Both artefacts stay **visible and auditable to the owner** afterwards: `GET /projects/{p}/webhooks` still shows `{\"created_by\":\"collab\"}` and `GET /projects/{p}/shares` still shows `{\"shared_by\":\"collab\"}`. An administrator reviewing project settings after an offboarding will find them. That is genuinely weaker than a silent channel, and it argues for the low end of Medium.\n\nThe precondition is also real: the attacker held write access, so they could have taken a snapshot before leaving. **The only thing new here is access to content created after revocation** \u2014 which is precisely the line you drew yourselves in `GHSA-jp29-jrxc-92vf`, *\"favourites readable after revocation\"*. We think it holds. It is also the entirety of the claim, and we are not dressing it up as more.\n\n## Affected range\n\n**All releases from `v0.22.0` through `v2.6.0`, and current `main`.**\n\nDetermined by checking the code at each released tag:\n\n```\nv0.22.0 \u2026 v0.24.6 webhooks.go=yes cleanupRoutine=0\nv1.0.0 \u2026 v2.6.0 webhooks.go=yes cleanupRoutine=1\n```\n\nProject webhooks arrive in `ad7d485eb` (2023-10-17), first released in v0.22.0. The cleanup routine arrives in `9358954c9` (2025-10-09), first released in v1.0.0, and has never included webhooks or link shares. Still present on `main` at `d822e1c58`: the routine contains only `Delete(\u0026TaskAssginee{})` and two `Delete(\u0026Subscription{})`, and `ProjectUser.Delete` contains zero dispatches.\n\nReproduced at v2.6.0; earlier versions asserted from source rather than run, and we are saying which is which.\n\n## Recommended Fix\n\nTwo changes, and they are independent \u2014 the first is the smaller one, the second is the one that closes the class.\n\n**Add the two row types to the cleanup set.** Alongside the existing `task_assignees` and `subscriptions` deletions, delete `webhooks` and `link_shares` whose `created_by` / `shared_by` is the departing user and whose project is in `projectsToCleanup`. The existing live `project.CanRead` test is already the right predicate.\n\n**Dispatch the cleanup from all four revocation paths**, not only team-member removal. `ProjectUser.Delete` and `ProjectUser.Update` (the downgrade case) are the common operations and currently fire nothing; `TeamProject.Delete` unshares a whole project from a team and is equally a revocation.\n\nA cheaper alternative for the second half, if reworking dispatch is unattractive: check `CanRead` for the webhook\u0027s `created_by` at delivery time, and for the share\u0027s `shared_by` at redemption time. That converts a cleanup problem into an authorization check on a path that already has the user id to hand.\n\n## Severity\n\n`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` \u2014 **6.5 Medium**.\n\nThis is **the identical vector you assigned to your own webhook advisory**, `GHSA-7c2g-p23p-4jg3` (webhook BasicAuth credentials exposed to read-only members), copied rather than argued. `PR:L` because the attacker must have been provisioned with project write at some point; `C:H` because the channel carries full task titles and descriptions for the whole project continuously \u2014 the same `C:H` you assigned there for a credential leak of narrower scope.\n\nThe auditability caveat above argues for the low end of Medium and we would not contest a lower score.\n\n### The link share is strictly more capable, and we are not leading with it\n\nThe same gap leaves a link share created by the departing collaborator redeemable after revocation, and a link share carries **read and write** \u2014 HTTP 201 demonstrated. On the same reasoning that would be `C:H/I:H` = 8.1 High.\n\nWe are deliberately **not** proposing that, and leading with the webhook instead, because a link share has a real *\"it is designed to be handed out\"* defence and the webhook does not. That judgement is yours to make, and if you decide the share is the more serious half we will not argue.",
"id": "GHSA-hjx8-qv73-f7cm",
"modified": "2026-10-09T20:57:41Z",
"published": "2026-10-09T20:57:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-hjx8-qv73-f7cm"
},
{
"type": "PACKAGE",
"url": "https://github.com/go-vikunja/vikunja"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vikunja: Webhooks and link shares survive every revocation path, so a removed collaborator keeps a live feed"
}
GHSA-HM74-HHR5-RW72
Vulnerability from github – Published: 2026-10-20 00:32 – Updated: 2026-10-20 00:32IBM Storage TS4500 Library 1.1.1.6 through 1.12.0.3 IBM TS4500 Tape Library/Diamondback Tape Library does not invalidate session which could allow an authenticated user to impersonate another user on the system.
{
"affected": [],
"aliases": [
"CVE-2025-36252"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-19T23:17:35Z",
"severity": "MODERATE"
},
"details": "IBM Storage TS4500 Library 1.1.1.6 through 1.12.0.3 IBM TS4500 Tape Library/Diamondback Tape Library does not invalidate session which could allow an authenticated user to impersonate another user on the system.",
"id": "GHSA-hm74-hhr5-rw72",
"modified": "2026-10-20T00:32:00Z",
"published": "2026-10-20T00:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36252"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7292611"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HMPP-GH47-8R55
Vulnerability from github – Published: 2022-05-14 03:30 – Updated: 2022-05-14 03:30Philips ISCV application prior to version 2.3.0 has an insufficient session expiration vulnerability where an attacker could reuse the session of a previously logged in user. This vulnerability exists when using ISCV together with an Electronic Medical Record (EMR) system, where ISCV is in KIOSK mode for multiple users and using Windows authentication. This may allow an attacker to gain unauthorized access to patient health information and potentially modify this information.
{
"affected": [],
"aliases": [
"CVE-2018-5438"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-03-20T17:29:00Z",
"severity": "MODERATE"
},
"details": "Philips ISCV application prior to version 2.3.0 has an insufficient session expiration vulnerability where an attacker could reuse the session of a previously logged in user. This vulnerability exists when using ISCV together with an Electronic Medical Record (EMR) system, where ISCV is in KIOSK mode for multiple users and using Windows authentication. This may allow an attacker to gain unauthorized access to patient health information and potentially modify this information.",
"id": "GHSA-hmpp-gh47-8r55",
"modified": "2022-05-14T03:30:15Z",
"published": "2022-05-14T03:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5438"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSMA-18-025-01"
},
{
"type": "WEB",
"url": "https://www.usa.philips.com/healthcare/about/customer-support/product-security"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/102847"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Set sessions/credentials expiration date.
No CAPEC attack patterns related to this CWE.