[TT-16259] [Security] Unable to delete Session that uses a quota and is under heavy load [Plan A] by shults · Pull Request #8254 · TykTechnologies/tyk

shults · 2026-05-27T15:16:29Z

Description

Related Issue

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

I ensured that the documentation is up to date
I explained why this PR updates go.mod in detail with reasoning why it's required
I would like a code coverage CI quality gate exception and have explained why

Ticket Details

TT-16259


Status	In Code Review
Summary	[Security] Unable to delete Session that uses a quota and is under heavy load

Generated at: 2026-06-05 11:28:49

probelabs · 2026-05-27T15:17:32Z

This pull request addresses a critical security vulnerability (TT-16259) where a session utilizing a quota could be recreated after deletion if the system is under heavy load. The root cause is a race condition: an in-flight request, authenticated before the session's deletion, would write the session back to the data store upon completion to update its state (e.g., quota usage), effectively "resurrecting" the deleted session.

The fix introduces an "update-if-exists" strategy for session persistence. A new isRestored flag is added to the user.SessionState struct to differentiate between new sessions and those loaded from storage. The session update logic in gateway.DefaultSessionManager.UpdateSession now leverages this flag to call new SetKeyEx or SetRawKeyEx methods for these restored sessions. These methods, implemented in the storage layer, will only update a key if it already exists. For the Redis backend, this is achieved atomically using the SET ... XX command, which is the core of this security fix.

This PR also includes a significant refactoring of the storage.Handler interface, breaking it down into smaller, single-responsibility interfaces, which improves modularity and testability across the storage layer.

Files Changed Analysis

The changes span 29 files with 1090 additions and 56 deletions, primarily impacting the gateway and storage layers.

Core Logic:
- user/session.go: The SessionState struct is enhanced with an isRestored flag to track its lifecycle.
- gateway/auth_manager.go: UpdateSession now uses conditional logic, calling SetKeyEx/SetRawKeyEx for restored sessions to prevent their recreation. SessionDetail is updated to mark any session fetched from storage as restored.
Storage Layer:
- storage/storage.go: The storage.Handler interface is refactored into multiple granular interfaces (e.g., SetKeyHandler, GetKeyHandler) and extended with SetKeyExHandler and SetRawKeyExHandler for the new conditional update logic.
- storage/redis_cluster.go: The new SetKeyEx and SetRawKeyEx methods are implemented using Redis's SET ... XX command, providing the atomic "update-if-exists" guarantee.
- Other storage backends (gateway/rpc_storage_handler.go, gateway/ldap_auth_handler.go, storage/mdcb_storage.go) are updated to comply with the new interface, but their implementations of the new methods are incomplete or insecure (e.g., no-ops or insecure fallbacks), limiting the effectiveness of the fix to Redis-only deployments.
Dependencies & Testing:
- go.mod/go.sum: The storage module dependency is updated.
- log/: New test hook helpers are added to improve logging-related tests.
- Extensive new tests are added, particularly in gateway/auth_manager_test.go and gateway/rpc_storage_handler_test.go, to cover the new logic.

Architecture & Impact Assessment

What this PR accomplishes: It patches a critical race condition that allowed for the resurrection of deleted user sessions, hardening the gateway's session management against concurrent access patterns.
Key technical changes introduced:
1. Conditional Persistence: Introduction of an "update-if-exists" semantic (SetKeyEx, SetRawKeyEx) into the storage abstraction layer.
2. Session State Lifecycle: Addition of an isRestored flag to user.SessionState to enable more intelligent persistence logic.
3. Interface Segregation: A major refactoring of the storage.Handler interface into smaller, role-based interfaces, improving code structure and maintainability.
Affected system components: The changes primarily affect the Gateway Authentication and Session Management systems and the Storage Layer. The interface refactoring impacts all existing and future storage implementations.

Race Condition and Fix Visualization

sequenceDiagram
    participant Admin
    participant User
    participant Gateway
    participant Redis

    Admin->>Gateway: DELETE /session/{key}
    Gateway->>Redis: DEL {key}
    Redis-->>Gateway: OK

    par In-flight Request (Authenticated before DEL)
        User->>Gateway: GET /api (with {key})
        Note right of Gateway: Request proceeds, session is updated in memory (e.g., quota)
        Gateway->>Redis: SET {key} '...' XX (update-if-exists)
        Note over Redis: Key does not exist, so SET command fails
        Redis-->>Gateway: (nil)
        Note right of Gateway: Session is NOT recreated.
    end

Scope Discovery & Context Expansion

Broader Impact: The storage.Handler refactoring is a wide-reaching change. Critically, the security fix is only fully implemented for the Redis backend. Other storage handlers receive incomplete or insecure implementations for the new methods. For instance, gateway/rpc_storage_handler.go implements SetKeyEx with an insecure fallback to SetKey and SetRawKeyEx as a no-op. This means the security fix will be silently bypassed in deployments using RPC for session storage, which is a significant risk that needs to be addressed.
Identified Latent Bug: A todo comment was added in gateway/session_manager.go, highlighting a pre-existing atomicity issue in the Redis quota logic. The current pipelined INCR and EXPIRE is not atomic and could lead to quota keys persisting indefinitely. This should be tracked and fixed in a separate ticket.
Refactoring Note: The sessionStore parameter was removed from APISpec.Init in gateway/api_definition.go. This is a safe cleanup of a previously unused parameter and does not alter system behavior.

Metadata

Review Effort: 4 / 5
Primary Label: bug

Powered by Visor from Probelabs

Last updated: 2026-06-10T05:45:12.568Z | Triggered by: pr_updated | Commit: 0fe41ab

💡 TIP: You can chat with Visor using /visor ask <your question>

github-actions · 2026-05-27T15:17:32Z

🎯 Recommended Merge Targets

Based on JIRA ticket TT-16259: [Security] Unable to delete Session that uses a quota and is under heavy load

Fix Version: Tyk 5.8.15

Required:

release-5.8 - Minor version branch for 5.8.x patches - required for creating Tyk 5.8.15
master - Main development branch - ensures fix is in all future releases

Fix Version: Tyk 5.13.1

Required:

release-5.13 - Minor version branch for 5.13.x patches - required for creating Tyk 5.13.1
master - Main development branch - ensures fix is in all future releases

Fix Version: Tyk 5.14.0

⚠️ Warning: Expected release branches not found in repository

Required:

master - No matching release branches found. Fix will be included in future releases.

📋 Workflow

Merge this PR to master first
Cherry-pick to release branches by commenting on the merged PR:
- /release to release-5.8
- /release to release-5.13
Automated backport - The bot will automatically create backport PRs to the specified release branches

probelabs · 2026-05-27T15:18:02Z

Security Issues (3)

Severity	Location	Issue
🔴 Critical	`gateway/rpc_storage_handler.go:421-425`	The `SetKeyEx` method, intended to prevent a session resurrection vulnerability, has an insecure fallback to the `SetKey` method. If the remote MDCB does not support `SetKeyEx`, it silently reverts to the old, vulnerable behavior of creating/overwriting the session key. This completely negates the security fix for deployments with older MDCB versions. 💡 Suggestion Remove the fallback logic. The operation should fail explicitly if the secure `SetKeyEx` method is not supported by the remote endpoint. This ensures a fail-safe behavior and alerts administrators to the configuration mismatch, preventing silent vulnerabilities.
🔴 Critical	`gateway/rpc_storage_handler.go:430-433`	The `SetRawKeyEx` method is implemented as a no-op, returning `nil` without performing any action. When sessions use hashed keys, this causes all session updates to be silently ignored by the RPC storage handler. This not only breaks functionality like quota tracking but also renders the security fix completely ineffective for this configuration. 💡 Suggestion The `SetRawKeyEx` method must be fully implemented to perform a conditional 'update-if-exists' operation via RPC, similar to `SetKeyEx`. If this functionality cannot be supported, the method should return an error to prevent silent failures and a false sense of security.
🟠 Error	`storage/mdcb_storage.go:75-93`	The `MdcbStorage` implementations for `SetKeyEx` and `SetRawKeyEx` only perform the conditional update on the local cache (`m.local`) and do not propagate the operation to the remote RPC handler (`m.rpc`). In a multi-datacenter environment using MDCB, this could lead to the session resurrection vulnerability persisting, as a deleted session could be recreated by a write from another datacenter. 💡 Suggestion Modify `SetKeyEx` and `SetRawKeyEx` in `MdcbStorage` to also invoke the corresponding methods on the `m.rpc` handler. This will ensure that the 'update-if-exists' logic is consistently applied across all nodes in the cluster.

Architecture Issues (3)

Severity	Location	Issue
🔴 Critical	`gateway/rpc_storage_handler.go:421-425`	The `SetKeyEx` implementation in `RPCStorageHandler` falls back to the non-conditional `SetKey` operation if the remote endpoint does not support `SetKeyEx`. This fallback silently re-introduces the security vulnerability (a race condition allowing deleted sessions to be recreated) that this pull request is intended to fix. Prioritizing backward compatibility over security in this context creates a significant risk, as deployments using older MDCB versions will remain vulnerable without any explicit failure or warning. 💡 Suggestion Remove the fallback logic. If the `SetKeyEx` method is not supported by the remote endpoint, the function should return an error. This ensures the system fails safe and does not operate in an insecure state. An explicit failure is better than a silent vulnerability.
🟠 Error	`gateway/rpc_storage_handler.go:431-434`	`SetRawKeyEx` is implemented as a no-op, returning `nil` without performing any action. This violates the storage handler's contract, as callers will assume the conditional update succeeded when it was silently ignored. This can lead to data inconsistency and unpredictable behavior, particularly for features like quota management that rely on session state updates. 💡 Suggestion Implement the `SetRawKeyEx` method to perform a conditional "update-if-exists" operation via RPC. If the RPC interface does not support this, the method should return an `errors.New("not implemented")` to make the failure explicit rather than silently succeeding.
🟠 Error	`storage/mdcb_storage.go:78-89`	The `MdcbStorage` type acts as a hybrid store, coordinating between a local cache and a remote RPC store. However, the new `SetKeyEx` and `SetRawKeyEx` methods only delegate to the `local` store and do not propagate the operation to the `rpc` store. This breaks the abstraction and will cause data inconsistency between the local and remote storage layers, defeating the purpose of the hybrid storage model. 💡 Suggestion Update the `SetKeyEx` and `SetRawKeyEx` methods to propagate the calls to the `rpc` handler in addition to the `local` handler. This will ensure that the conditional update is applied consistently across both storage layers.

Security Issues (3)

Severity	Location	Issue
🔴 Critical	`gateway/rpc_storage_handler.go:421-425`	The `SetKeyEx` method, intended to prevent a session resurrection vulnerability, has an insecure fallback to the `SetKey` method. If the remote MDCB does not support `SetKeyEx`, it silently reverts to the old, vulnerable behavior of creating/overwriting the session key. This completely negates the security fix for deployments with older MDCB versions. 💡 Suggestion Remove the fallback logic. The operation should fail explicitly if the secure `SetKeyEx` method is not supported by the remote endpoint. This ensures a fail-safe behavior and alerts administrators to the configuration mismatch, preventing silent vulnerabilities.
🔴 Critical	`gateway/rpc_storage_handler.go:430-433`	The `SetRawKeyEx` method is implemented as a no-op, returning `nil` without performing any action. When sessions use hashed keys, this causes all session updates to be silently ignored by the RPC storage handler. This not only breaks functionality like quota tracking but also renders the security fix completely ineffective for this configuration. 💡 Suggestion The `SetRawKeyEx` method must be fully implemented to perform a conditional 'update-if-exists' operation via RPC, similar to `SetKeyEx`. If this functionality cannot be supported, the method should return an error to prevent silent failures and a false sense of security.
🟠 Error	`storage/mdcb_storage.go:75-93`	The `MdcbStorage` implementations for `SetKeyEx` and `SetRawKeyEx` only perform the conditional update on the local cache (`m.local`) and do not propagate the operation to the remote RPC handler (`m.rpc`). In a multi-datacenter environment using MDCB, this could lead to the session resurrection vulnerability persisting, as a deleted session could be recreated by a write from another datacenter. 💡 Suggestion Modify `SetKeyEx` and `SetRawKeyEx` in `MdcbStorage` to also invoke the corresponding methods on the `m.rpc` handler. This will ensure that the 'update-if-exists' logic is consistently applied across all nodes in the cluster.

\n\n ### Architecture Issues (3)

Severity	Location	Issue
🔴 Critical	`gateway/rpc_storage_handler.go:421-425`	The `SetKeyEx` implementation in `RPCStorageHandler` falls back to the non-conditional `SetKey` operation if the remote endpoint does not support `SetKeyEx`. This fallback silently re-introduces the security vulnerability (a race condition allowing deleted sessions to be recreated) that this pull request is intended to fix. Prioritizing backward compatibility over security in this context creates a significant risk, as deployments using older MDCB versions will remain vulnerable without any explicit failure or warning. 💡 Suggestion Remove the fallback logic. If the `SetKeyEx` method is not supported by the remote endpoint, the function should return an error. This ensures the system fails safe and does not operate in an insecure state. An explicit failure is better than a silent vulnerability.
🟠 Error	`gateway/rpc_storage_handler.go:431-434`	`SetRawKeyEx` is implemented as a no-op, returning `nil` without performing any action. This violates the storage handler's contract, as callers will assume the conditional update succeeded when it was silently ignored. This can lead to data inconsistency and unpredictable behavior, particularly for features like quota management that rely on session state updates. 💡 Suggestion Implement the `SetRawKeyEx` method to perform a conditional "update-if-exists" operation via RPC. If the RPC interface does not support this, the method should return an `errors.New("not implemented")` to make the failure explicit rather than silently succeeding.
🟠 Error	`storage/mdcb_storage.go:78-89`	The `MdcbStorage` type acts as a hybrid store, coordinating between a local cache and a remote RPC store. However, the new `SetKeyEx` and `SetRawKeyEx` methods only delegate to the `local` store and do not propagate the operation to the `rpc` store. This breaks the abstraction and will cause data inconsistency between the local and remote storage layers, defeating the purpose of the hybrid storage model. 💡 Suggestion Update the `SetKeyEx` and `SetRawKeyEx` methods to propagate the calls to the `rpc` handler in addition to the `local` handler. This will ensure that the conditional update is applied consistently across both storage layers.

\n\n ### Performance Issues (3)

Severity	Location	Issue
🟡 Warning	`gateway/rpc_storage_handler.go:1444-1452`	The `retryAlways` decorator implements a retry loop (`for {}`) without any backoff or delay between retries. In scenarios with persistent retriable errors, this can lead to a tight loop that consumes excessive CPU and network resources, potentially exacerbating load on the RPC server or causing the gateway to become unresponsive. 💡 Suggestion Introduce an exponential backoff with jitter to the retry logic. The `github.com/cenk/backoff` package, which is already a dependency and used elsewhere in the codebase, would be a suitable choice. This will prevent busy-waiting under failure conditions and give the downstream service time to recover.
🟡 Warning	`gateway/session_manager.go:501-507`	The code uses a Redis pipeline to perform an `INCR` operation and conditionally set an `EXPIRE`. As noted in the new `todo` comment, this operation is not atomic. If the gateway process is interrupted or the connection is lost between the `INCR` and `EXPIRE` commands, the quota key will be left without a TTL, leading to a memory leak in Redis as the key will persist indefinitely. 💡 Suggestion To ensure atomicity, replace the pipelined commands with a Lua script that performs the `INCR` and `EXPIRE` operations together. This guarantees that quota keys are always created with a TTL, preventing resource leaks in Redis.
🟡 Warning	`gateway/rpc_storage_handler.go:429-432`	The fallback mechanism for `SetKeyEx` to `SetKey` for older MDCB versions introduces an additional network round-trip when the gateway is connected to an older MDCB instance that does not support `SetKeyEx`. This degrades performance for session updates in such environments, as it requires one failed RPC call followed by a second successful one. 💡 Suggestion While this provides backward compatibility, it's important to be aware of the performance cost. Consider adding metrics to track the frequency of this fallback to help operators identify outdated MDCB instances that require upgrading to improve performance.

Quality Issues (5)

Severity	Location	Issue
🔴 Critical	`gateway/rpc_storage_handler.go:431-434`	The `SetRawKeyEx` function is implemented as a no-op, returning `nil` without performing any action. This is critical because hashed keys, which are commonly used, rely on `SetRawKeyEx`. By not implementing this function, the security fix is completely bypassed for such keys, allowing the session recreation vulnerability to persist in deployments using RPC storage. 💡 Suggestion Implement `SetRawKeyEx` to perform a conditional set operation via RPC, similar to `SetKeyEx`. If the RPC endpoint does not support a raw key conditional set, this function should return an error rather than silently failing.
🔴 Critical	`gateway/rpc_storage_handler.go:425`	The `internalSetKeyEx` function falls back to using the insecure `SetKey` method if the RPC server reports `SetKeyEx` as an "unknown method". This fallback silently disables the security fix and reintroduces the original race condition vulnerability. A security mechanism should fail-closed rather than silently degrading to an insecure state. 💡 Suggestion Remove the fallback logic. If the remote MDCB instance does not support `SetKeyEx`, the operation should fail with an error. This ensures that administrators are aware of the configuration mismatch and that the system does not operate in an insecure mode.
🟠 Error	`storage/mdcb_storage.go:75-89`	The `SetKeyEx` and `SetRawKeyEx` methods in `MdcbStorage` only call the corresponding methods on the `local` storage handler. Unlike the `SetKey` method, they do not broadcast the change to other nodes via RPC. In a multi-gateway deployment using MDCB, this means the conditional update is only performed on the local node's cache, and the central session state is not updated, rendering the fix ineffective in a distributed environment. 💡 Suggestion Update `SetKeyEx` and `SetRawKeyEx` to broadcast the operation via RPC, similar to how `SetKey` uses `m.broadcast()`. This will require adding corresponding handlers on the RPC server side.
🟡 Warning	`user/session.go:385-392`	The comments for `MarkAsRestored` and `IsRestored` are confusing. `MarkAsRestored`'s comment says it "marks the session as new", and `IsRestored`'s comment says it "informs if session is a new one". This is the opposite of their function. A restored session is one that was loaded from storage, not a new one. 💡 Suggestion Clarify the comments to accurately reflect the purpose of the flag and methods. For example: `// MarkAsRestored marks the session as having been loaded from storage.` and `// IsRestored returns true if the session was loaded from storage.`
🟡 Warning	`storage/dummy_test.go:651`	The test case name `does not set if key already exist` is incorrect. The test actually verifies that the key is not set if it does not exist, which is the correct behavior for `Set...Ex` methods. 💡 Suggestion Rename the test case to `does not set if key does not exist` to accurately describe the behavior being tested.

Powered by Visor from Probelabs

Last updated: 2026-06-10T05:44:49.267Z | Triggered by: pr_updated | Commit: 0fe41ab

💡 TIP: You can chat with Visor using /visor ask <your question>

shults · 2026-06-05T08:10:05Z

/visor ask "SetRawKeyEx" is implemented the same way as "SetRawKey" for MDCBStorage; If someone uses this MDCBStorage as session storage, it will fail anyway. So it is not a problem at all from my point of view.

probelabs · 2026-06-05T08:11:37Z

Powered by Visor from Probelabs

Last updated: 2026-06-05T08:11:36.883Z | Triggered by: shults | Commit: 749796e

💡 TIP: You can chat with Visor using /visor ask <your question>

shults · 2026-06-05T11:26:39Z

/visor ask APISpec.Init session store was not used; there was no reason of precence that parameter

probelabs · 2026-06-05T11:27:31Z

Powered by Visor from Probelabs

Last updated: 2026-06-05T11:27:30.825Z | Triggered by: shults | Commit: 29ae8f5

💡 TIP: You can chat with Visor using /visor ask <your question>

probelabs · 2026-06-09T11:08:50Z

I've analyzed the concerns raised in the comments regarding serialization and refactoring:

1. Serialization of isRestored:
@kofoworola's concern about isRestored being lost over the wire is technically correct (since it's an unexported field, it won't be serialized to JSON). However, as @shults pointed out, this is safe by design. The isRestored flag is strictly a local runtime marker used by the gateway to determine whether to use SetKey (create) or SetKeyEx (update).

When a node fetches a session from storage, it explicitly calls MarkAsRestored() after deserialization.
When the session is sent to MDCB, it's sent as a JSON string and saved directly to storage without being deserialized back into a SessionState struct.
Therefore, the flag doesn't need to be transmitted over the wire.

2. Refactoring of storage.Handler:
The refactoring is a solid application of the Interface Segregation Principle (ISP). Previously, storage.Handler was a monolithic interface with ~40 methods. By breaking it down into single-method interfaces (e.g., GetKeyHandler, SetKeyHandler), components can now depend only on the methods they actually use. A great example of this benefit in this PR is in certs/manager.go, where a local StorageHandler interface is defined that embeds only the 9 specific methods it needs, reducing coupling and making mocking much easier.

…-that-uses-a-quota-and-is-under-heavy-load

github-actions · 2026-06-10T05:43:31Z

🚨 Jira Linter Failed

Commit: 0fe41ab
Failed at: 2026-06-10 05:43:29 UTC

The Jira linter failed to validate your PR. Please check the error details below:

🔍 Click to view error details

failed to get Jira issue: failed to fetch Jira issue TT-16259: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

Next Steps

Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
Verify your PR title matches the branch's Jira ticket ID
Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

sonarqubecloud · 2026-06-10T07:17:50Z

Quality Gate passed

Issues
11 New issues
0 Accepted issues

Measures
0 Security Hotspots
92.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

shults · 2026-06-10T13:30:45Z

/release to release-5.8

shults · 2026-06-10T13:31:09Z

/release to release-5.13

probelabs · 2026-06-11T05:17:09Z

✅ Cherry-pick successful. A PR was created: #8305

shults · 2026-06-11T08:30:00Z

/release to release-5.13

probelabs · 2026-06-11T08:30:23Z

✅ Cherry-pick successful. A PR was created: #8306

…ota and is under heavy load [Plan A] (#8254)" This reverts commit 989c668.

…ota and is under heavy load [Plan A] (#8254)" This reverts commit 989c668.  ## Description  ## Related Issue     ## Motivation and Context  ## How This Has Been Tested     ## Screenshots (if appropriate) ## Types of changes  - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality) ## Checklist    - [ ] I ensured that the documentation is up to date - [ ] I explained why this PR updates go.mod in detail with reasoning why it's required - [ ] I would like a code coverage CI quality gate exception and have explained why

lghiur added the deps-reviewed Dependency changes reviewed and approved for CI execution label May 28, 2026

shults force-pushed the TT-16259-security-unable-to-delete-session-that-uses-a-quota-and-is-under-heavy-load branch 2 times, most recently from 758d1bf to 21d5f0f Compare May 28, 2026 09:23

shults closed this May 28, 2026

shults reopened this May 28, 2026

shults changed the title ~~[TT-16259] [Security] Unable to delete Session that uses a quota and is under heavy load~~ [TT-16259] [Security] Unable to delete Session that uses a quota and is under heavy load [Plan A] May 28, 2026

radkrawczyk closed this May 29, 2026

radkrawczyk reopened this May 29, 2026

shults requested review from MFCaballero, MaciekMis and kofoworola June 1, 2026 14:02

shults force-pushed the TT-16259-security-unable-to-delete-session-that-uses-a-quota-and-is-under-heavy-load branch from 98316f1 to 8ad76e6 Compare June 5, 2026 06:32

shults force-pushed the TT-16259-security-unable-to-delete-session-that-uses-a-quota-and-is-under-heavy-load branch from fe65b4a to 2dae261 Compare June 5, 2026 11:28

radkrawczyk reviewed Jun 8, 2026

View reviewed changes

Comment thread go.mod Outdated

shults force-pushed the TT-16259-security-unable-to-delete-session-that-uses-a-quota-and-is-under-heavy-load branch 3 times, most recently from 1fa04d0 to a9b1103 Compare June 9, 2026 07:45

kofoworola requested changes Jun 9, 2026

View reviewed changes

Comment thread storage/storage.go

Comment thread user/session.go

shults added 5 commits June 9, 2026 12:08

poc

32e362c

go mod

348c10e

fix failing tests

3bddaa3

try fix some tests

a817869

invert logic

7fc517e

shults and others added 8 commits June 9, 2026 12:08

try fix tests

f1641ec

remove logs check

3b4fdb5

add decorator tests

4984631

extract method internalSetKeyEx

0eeedd7

add hoiok tests

82a5df8

extend

2eca2c4

test: add unit tests for internalSetKeyEx and SetRawKeyEx

b708ffd

go.mod: bump storage version

aab5a4f

shults force-pushed the TT-16259-security-unable-to-delete-session-that-uses-a-quota-and-is-under-heavy-load branch from 27093de to aab5a4f Compare June 9, 2026 10:10

shults requested a review from kofoworola June 9, 2026 14:54

kofoworola approved these changes Jun 9, 2026

View reviewed changes

radkrawczyk added 2 commits June 10, 2026 07:25

Merge branch 'master' into TT-16259-security-unable-to-delete-session…

558e6ec

…-that-uses-a-quota-and-is-under-heavy-load

Merge branch 'master' into TT-16259-security-unable-to-delete-session…

0fe41ab

…-that-uses-a-quota-and-is-under-heavy-load

MaciekMis approved these changes Jun 10, 2026

View reviewed changes

Comment thread gateway/session_manager.go

radkrawczyk merged commit 989c668 into master Jun 10, 2026
73 of 100 checks passed

radkrawczyk deleted the TT-16259-security-unable-to-delete-session-that-uses-a-quota-and-is-under-heavy-load branch June 10, 2026 08:38

shults mentioned this pull request Jun 11, 2026

Revert TT-16259 #8307

Merged

7 tasks

kofoworola pushed a commit that referenced this pull request Jun 11, 2026

Revert "[TT-16259] [Security] Unable to delete Session that uses a qu…

03ec7c1

…ota and is under heavy load [Plan A] (#8254)" This reverts commit 989c668.

kofoworola pushed a commit that referenced this pull request Jun 12, 2026

Revert "[TT-16259] [Security] Unable to delete Session that uses a qu…

75220f1

…ota and is under heavy load [Plan A] (#8254)" This reverts commit 989c668.

kofoworola pushed a commit that referenced this pull request Jun 12, 2026

Revert "[TT-16259] [Security] Unable to delete Session that uses a qu…

f4ea04f

…ota and is under heavy load [Plan A] (#8254)" This reverts commit 989c668.

kofoworola pushed a commit that referenced this pull request Jun 15, 2026

Revert "[TT-16259] [Security] Unable to delete Session that uses a qu…

844afc8

…ota and is under heavy load [Plan A] (#8254)" This reverts commit 989c668.

Uh oh!

Conversation

shults commented May 27, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issue

Motivation and Context

How This Has Been Tested

Screenshots (if appropriate)

Types of changes

Checklist

Ticket Details

Uh oh!

probelabs Bot commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Files Changed Analysis

Architecture & Impact Assessment

Race Condition and Fix Visualization

Scope Discovery & Context Expansion

Uh oh!

github-actions Bot commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🎯 Recommended Merge Targets

Fix Version: Tyk 5.8.15

Fix Version: Tyk 5.13.1

Fix Version: Tyk 5.14.0

📋 Workflow

Uh oh!

probelabs Bot commented May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Security Issues (3)

Architecture Issues (3)

Security Issues (3)

Quality Issues (5)

Uh oh!

shults commented Jun 5, 2026

Uh oh!

probelabs Bot commented Jun 5, 2026

Uh oh!

shults commented Jun 5, 2026

Uh oh!

probelabs Bot commented Jun 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

probelabs Bot commented Jun 9, 2026

Uh oh!

github-actions Bot commented Jun 10, 2026

🚨 Jira Linter Failed

Next Steps

Uh oh!

sonarqubecloud Bot commented Jun 10, 2026

Quality Gate passed

Uh oh!

Uh oh!

Uh oh!

shults commented Jun 10, 2026

Uh oh!

shults commented Jun 10, 2026

Uh oh!

probelabs Bot commented Jun 11, 2026

Uh oh!

shults commented Jun 11, 2026

Uh oh!

probelabs Bot commented Jun 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

shults commented May 27, 2026 •

edited by github-actions Bot

Loading

probelabs Bot commented May 27, 2026 •

edited

Loading

github-actions Bot commented May 27, 2026 •

edited

Loading

probelabs Bot commented May 27, 2026 •

edited

Loading