Every CVE Search/ Get API key

CVE-2026-32245

Tinyauth's OIDC authorization codes are not bound to client on token exchange

6.5 MediumFix available

Tinyauth is an authentication and authorization server. Prior to 5.0.3, the OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3. This vulnerability is fixed in 5.0.3.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
High
Privileges needed
Low
User interaction
Required

What an attacker can affect

Confidentiality
Low
Integrity
High
Availability
None

Exploit likelihood

0.30%Up 0.3 points since Mar 13, 2026
90%50%10%1%

What each source reports

CVE List Score used 6.5

Tinyauth's OIDC authorization codes are not bound to client on token exchange

Tinyauth is an authentication and authorization server. Prior to 5.0.3, the OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3. This vulnerability is fixed in 5.0.3.

Record
CVE-2026-32245
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
EUVDEUVD-2026-11679 6.5

Tinyauth is an authentication and authorization server. Prior to 5.0.3, the OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3. This vulnerability is fixed in 5.0.3.

Record
EUVD-2026-11679
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N
Updated
2026-11-02
GitHub AdvisoriesGHSA-xg2q-62g2-cvcm 6.5

Tinyauth's OIDC authorization codes are not bound to client on token exchange

Summary

The OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3.

Details

When an authorization code is created, StoreCode at internal/service/oidc_service.go:305-322 correctly stores the ClientID alongside the code hash in the database (line 316).

During token exchange at internal/controller/oidc_controller.go:267-309, the handler retrieves the code entry at line 268 and validates the redirect_uri at line 291, but never compares entry.ClientID against the requesting client's ID (creds.ClientID). The code proceeds directly to GenerateAccessToken at line 299.

The developers clearly intended this check to exist, the refresh token flow at internal/service/oidc_service.go:508-510 has the exact guard: if entry.ClientID != reqClientId { return TokenResponse{}, ErrInvalidClient }. It was simply omitted from the authorization code grant.

The entry.ClientID field is stored in the database but never read during authorization code exchange.

PoC

Prerequisites: a tinyauth instance with two OIDC clients configured (Client A and Client B). Both clients must have at least one overlapping redirect URI, or the attacker must be able to intercept the authorization code from Client A's redirect (via referrer leak, browser history, log access, etc.).

Step 1 — Log in as a normal user:

curl -c cookies.txt -X POST http://localhost:3000/api/user/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin123"}'

Step 2 — Authorize with Client A:

curl -b cookies.txt -X POST http://localhost:3000/api/oidc/authorize \
  -H "Content-Type: application/json" \
  -d '{"client_id":"client-a-id","redirect_uri":"http://localhost:8080/callback","response_type":"code","scope":"openid","state":"test"}'

Extract the code parameter from the redirect_uri in the response.

Step 3 — Exchange Client A's code using Client B's credentials:

curl -X POST http://localhost:3000/api/oidc/token \
  -u "client-b-id:client-b-secret" \
  -d "grant_type=authorization_code&code=<CODE_FROM_STEP_2>&redirect_uri=http://localhost:8080/callback"

The server returns a valid access_token, id_token, and refresh_token. Client B has obtained tokens for a user who only authorized Client A.

Impact

A malicious OIDC relying party operator who can intercept or observe an authorization code issued to a different client can exchange it for tokens under their own client identity. This enables user impersonation across OIDC clients on the same tinyauth instance. The attack requires a multi-client deployment and a way to obtain the victim client's authorization code (which is passed as a URL query parameter and can leak through referrer headers, browser history, or server logs). Single-client deployments are not affected.

Record
GHSA-xg2q-62g2-cvcm
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
NVD 6.5

Tinyauth is an authentication and authorization server. Prior to 5.0.3, the OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3. This vulnerability is fixed in 5.0.3.

Record
CVE-2026-32245
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
OSV 6.5

Tinyauth's OIDC authorization codes are not bound to client on token exchange

Tinyauth is an authentication and authorization server. Prior to 5.0.3, the OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3. This vulnerability is fixed in 5.0.3.

Record
CVE-2026-32245
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
OSVGHSA-xg2q-62g2-cvcm 6.5

Tinyauth's OIDC authorization codes are not bound to client on token exchange

Summary

The OIDC token endpoint does not verify that the client exchanging an authorization code is the same client the code was issued to. A malicious OIDC client operator can exchange another client's authorization code using their own client credentials, obtaining tokens for users who never authorized their application. This violates RFC 6749 Section 4.1.3.

Details

When an authorization code is created, StoreCode at internal/service/oidc_service.go:305-322 correctly stores the ClientID alongside the code hash in the database (line 316).

During token exchange at internal/controller/oidc_controller.go:267-309, the handler retrieves the code entry at line 268 and validates the redirect_uri at line 291, but never compares entry.ClientID against the requesting client's ID (creds.ClientID). The code proceeds directly to GenerateAccessToken at line 299.

The developers clearly intended this check to exist, the refresh token flow at internal/service/oidc_service.go:508-510 has the exact guard: if entry.ClientID != reqClientId { return TokenResponse{}, ErrInvalidClient }. It was simply omitted from the authorization code grant.

The entry.ClientID field is stored in the database but never read during authorization code exchange.

PoC

Prerequisites: a tinyauth instance with two OIDC clients configured (Client A and Client B). Both clients must have at least one overlapping redirect URI, or the attacker must be able to intercept the authorization code from Client A's redirect (via referrer leak, browser history, log access, etc.).

Step 1 — Log in as a normal user:

curl -c cookies.txt -X POST http://localhost:3000/api/user/login \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"admin123"}'

Step 2 — Authorize with Client A:

curl -b cookies.txt -X POST http://localhost:3000/api/oidc/authorize \
  -H "Content-Type: application/json" \
  -d '{"client_id":"client-a-id","redirect_uri":"http://localhost:8080/callback","response_type":"code","scope":"openid","state":"test"}'

Extract the code parameter from the redirect_uri in the response.

Step 3 — Exchange Client A's code using Client B's credentials:

curl -X POST http://localhost:3000/api/oidc/token \
  -u "client-b-id:client-b-secret" \
  -d "grant_type=authorization_code&code=<CODE_FROM_STEP_2>&redirect_uri=http://localhost:8080/callback"

The server returns a valid access_token, id_token, and refresh_token. Client B has obtained tokens for a user who only authorized Client A.

Impact

A malicious OIDC relying party operator who can intercept or observe an authorization code issued to a different client can exchange it for tokens under their own client identity. This enables user impersonation across OIDC clients on the same tinyauth instance. The attack requires a multi-client deployment and a way to obtain the victim client's authorization code (which is passed as a URL query parameter and can leak through referrer headers, browser history, or server logs). Single-client deployments are not affected.

Record
GHSA-xg2q-62g2-cvcm
CVSS 3.1
6.5 MediumCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:N
Weakness
CWE-863
Updated
2026-11-02
OSVGO-2026-4689 No score

Tinyauth's OIDC authorization codes are not bound to client on token exchange in github.com/steveiliop56/tinyauth

Tinyauth's OIDC authorization codes are not bound to client on token exchange in github.com/steveiliop56/tinyauth.

NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions.

(If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.)

The additional affected modules and versions are: github.com/steveiliop56/tinyauth before v1.0.1-20260311144920-9eb2d33064b7.

Record
GO-2026-4689
Updated
2026-11-02
OSVopenSUSE-SU-2026:21483-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
  • GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
  • GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
  • GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
  • GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
  • GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
  • GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
  • GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
  • GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
  • GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
  • GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
  • GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
  • GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
  • GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
  • GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
  • GO-2026-5933 GHSA-3g4q-2f67-2gvh
  • GO-2026-5934 GHSA-59qp-cfj3-rp64
  • GO-2026-5935 GHSA-7856-g3gv-9wq8
  • GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
  • GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
  • GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
  • GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
  • GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
  • GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
  • GO-2026-5942 CVE-2026-46600
  • GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
  • GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
  • GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
  • GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
  • GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
  • GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
  • GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
  • GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
  • GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
  • GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
  • GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
  • GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
  • GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
  • GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
  • GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
  • GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
  • GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
  • GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
  • GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
  • GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
  • GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
  • GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
  • GO-2026-5969 GHSA-g936-7jqj-mwv8
  • GO-2026-5970 CVE-2026-56852
  • GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
  • GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
  • GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
  • GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
  • GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
  • GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
  • GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
  • GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
  • GO-2026-5981 GHSA-mqxv-9rm6-w8qc
  • GO-2026-5982 GHSA-pqg7-v6wh-3pfp
  • GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
  • GO-2026-5985 GHSA-7rx3-5wx3-5v76
  • GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
  • GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
  • GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
  • GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
  • GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
  • GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
  • GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
  • GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
  • GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
  • GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
  • GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
  • GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
  • GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
  • GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
  • GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
  • GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…
Record
openSUSE-SU-2026:21483-1
Updated
2026-11-02
OSVSUSE-SU-2026:1042-1 No score

Security update for govulncheck-vulndb

This update for govulncheck-vulndb fixes the following issues:

  • Update to version 0.0.20260317T205859 2026-03-17T20:58:59Z. Refs jsc#PED-11136 Go CVE Numbering Authority IDs added or updated with aliases:
    • GO-2026-4360 CVE-2026-0528 GHSA-w2gr-585j-r428
    • GO-2026-4513
    • GO-2026-4514
    • GO-2026-4518
    • GO-2026-4526
    • GO-2026-4549 CVE-2026-24005 GHSA-9fj4-3849-rv9g
    • GO-2026-4550 CVE-2026-1229 GHSA-q9hv-hpm4-hj6x
    • GO-2026-4551 CVE-2026-27575 GHSA-3ccg-x393-96v8
    • GO-2026-4552 CVE-2026-27116 GHSA-4qgr-4h56-8895
    • GO-2026-4553 CVE-2026-27616 GHSA-7jp5-298q-jg98
    • GO-2026-4554 CVE-2026-27730 GHSA-p2v6-84h2-5x4r
    • GO-2026-4556 CVE-2026-27819 GHSA-42wg-38gx-85rh
    • GO-2026-4557 CVE-2026-26186 GHSA-49xw-vfc4-7p43
    • GO-2026-4558 CVE-2026-27808 GHSA-mpf7-p9x7-96r3
    • GO-2026-4560 CVE-2026-27465 GHSA-2v6m-6xw3-6467
    • GO-2026-4561 CVE-2026-25963 GHSA-5jvp-m9h4-253h
    • GO-2026-4562 CVE-2026-27900 GHSA-5rc7-2jj6-mp64
    • GO-2026-4563 CVE-2026-24004 GHSA-9pm7-6g36-6j78
    • GO-2026-4564 CVE-2026-23999 GHSA-ppwx-5jq7-px2w
    • GO-2026-4565 CVE-2026-22728 GHSA-465p-v42x-3fmj
    • GO-2026-4566 CVE-2026-27899 GHSA-5rmx-256w-8mj9
    • GO-2026-4567 CVE-2026-27965 GHSA-8g8j-r87h-p36x
    • GO-2026-4568 GHSA-gj6x-q8rh-wj6x
    • GO-2026-4569 CVE-2026-27896 GHSA-wvj2-96wp-fq3f
    • GO-2026-4570 CVE-2026-27969 GHSA-r492-hjgh-c9gw
    • GO-2026-4571 CVE-2026-27734 GHSA-phwh-4f42-gwf3
    • GO-2026-4572 CVE-2026-27946 GHSA-282g-fhmx-xf54
    • GO-2026-4573 CVE-2026-27840 GHSA-6mq3-xmgp-pjm5
    • GO-2026-4574 CVE-2026-27945 GHSA-7777-fhq9-592v
    • GO-2026-4575 CVE-2026-28268 GHSA-rfjg-6m84-crj2
    • GO-2026-4576 CVE-2026-28280 GHSA-4rv8-5cmm-2r22
    • GO-2026-4577 CVE-2026-28407 GHSA-945p-3jhm-6rcp
    • GO-2026-4578 CVE-2025-14443 GHSA-gxvv-45f6-3ch8
    • GO-2026-4579 CVE-2026-28279 GHSA-rchw-322g-f7rm
    • GO-2026-4580 CVE-2026-28406 GHSA-6rxq-q92g-4rmf
    • GO-2026-4581 GHSA-xfx2-prg5-jq3g
    • GO-2026-4583 GHSA-54p8-x2m9-c593
    • GO-2026-4584 CVE-2026-28342 GHSA-pc8g-78pf-4xrp
    • GO-2026-4585 CVE-2026-28492 GHSA-mr74-928f-rw69
    • GO-2026-4586 CVE-2026-28789 GHSA-45m3-398w-m2m9
    • GO-2026-4587 CVE-2026-28790 GHSA-4fqm-6fmh-82mq
    • GO-2026-4588 CVE-2026-29049 GHSA-7rp8-r62p-q6wc
    • GO-2026-4589 CVE-2021-25320 GHSA-gqf8-rvrh-g7w6
    • GO-2026-4590 GHSA-hwm2-4ph6-w6m5
    • GO-2026-4591 CVE-2025-62879 GHSA-wj3p-5h3x-c74q
    • GO-2026-4592 CVE-2026-29073 GHSA-jqwg-75qf-vmf9
    • GO-2026-4593 CVE-2026-26998 GHSA-fw45-f5q2-2p4x
    • GO-2026-4594 CVE-2026-26999 GHSA-xw98-5q62-jx94
    • GO-2026-4595 CVE-2026-3351 GHSA-crmg-9m86-636r
    • GO-2026-4596 CVE-2026-29183 GHSA-6865-qjcf-286f
    • GO-2026-4597 CVE-2026-29054 GHSA-92mv-8f8w-wq52
    • GO-2026-4598 CVE-2026-29042 GHSA-95fj-3w7g-4r27
    • GO-2026-4599 CVE-2026-27137
    • GO-2026-4600 CVE-2026-27138
    • GO-2026-4601 CVE-2026-25679
    • GO-2026-4602 CVE-2026-27139
    • GO-2026-4603 CVE-2026-27142
    • GO-2026-4604 CVE-2026-29193 GHSA-25rw-g6ff-fmg8
    • GO-2026-4605 CVE-2026-29192 GHSA-6rx5-m2rc-hmf7
    • GO-2026-4606 CVE-2026-29188 GHSA-79pf-vx4x-7jmm
    • GO-2026-4607 CVE-2026-29191 GHSA-pr34-2v5x-6qjq
    • GO-2026-4608 CVE-2026-29771 GHSA-rhr9-hgcm-x289
    • GO-2026-4609 CVE-2026-29781 GHSA-hx52-cv84-jr5v
    • GO-2026-4610 CVE-2025-15558 GHSA-p436-gjf2-799p
    • GO-2026-4612 CVE-2026-28683 GHSA-3c22-5j5m-4jq7
    • GO-2026-4613 CVE-2026-28682 GHSA-c36c-7pc2-f2ph
    • GO-2026-4614 CVE-2026-27944 GHSA-g9w5-qffc-6762
    • GO-2026-4615 CVE-2026-29060 GHSA-m2hx-wjxc-9fp4
    • GO-2026-4616 CVE-2026-25921 GHSA-cj4v-437j-jq4c
    • GO-2026-4617 CVE-2026-26194 GHSA-v9vm-r24h-6rqm
    • GO-2026-4618 CVE-2026-26195 GHSA-vgvf-m4fw-938j
    • GO-2026-4619 CVE-2026-26196 GHSA-x9p5-w45c-7ffc
    • GO-2026-4620 CVE-2026-26022 GHSA-xrcr-gmf5-2r8j
    • GO-2026-4621 GHSA-fwhj-785h-43hh
    • GO-2026-4622 CVE-2026-30223 GHSA-g962-2j28-3cg9
    • GO-2026-4623 CVE-2026-30224 GHSA-gq2m-77hf-vwgh
    • GO-2026-4624 CVE-2026-29084 GHSA-hcff-qv74-7hr4
    • GO-2026-4625 CVE-2026-30225 GHSA-p443-p7w5-2f7f
    • GO-2026-4626 CVE-2026-29061…
Record
SUSE-SU-2026:1042-1
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/steveiliop56/tinyauth
Go
before 1.0.1-20260311144920-9eb2d33064b7
1.0.1-20260311144920-9eb2d33064b7
github.com/steveiliop56/tinyauth
Go
All versions None known
govulncheck-vulndb
openSUSE:Leap 15.6
From an advisory covering 124 CVEs
before 0.0.20260317T205859-150000.1.152.1
0.0.20260317T205859-150000.1.152.1
govulncheck-vulndb
openSUSE:Leap 16.0
From an advisory covering 1734 CVEs
before 0.0.20260723T184607-160000.1.1
0.0.20260723T184607-160000.1.1

History

History
RecordedChangedSources
affected, facts
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-32245 is a medium vulnerability (CVSS 6.5) in Steveiliop56 Tinyauth, published March 12, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.30%, the 22nd percentile. Fixed in github.com/steveiliop56/tinyauth 1.0.1-20260311144920-9eb2d33064b7.

References

Show 194 moreShow less
This page doesn't list everything

Left out here: 1,543 references and the rest of 2 source descriptions. The JSON record has them.

MoveEnter Open