|
1 | 1 | { |
2 | 2 | "vcs_url": "https://github.com/zulip/zulip", |
3 | 3 | "vulnerabilities": { |
| 4 | + "CVE-2023-28623": { |
| 5 | + "0903ea766f651d32201cffa0fad871e7a9f08201": "registration: Don't require LDAP auth for externally-verified users.\n\nOn servers with both ZulipLDAPAuthBackend and an external\nauthentication method (e.g. SAML) enabled, a new user who exists in\nthe LDAP directory could not complete signup via the external\nmethod: the registration code path required LDAP authentication to\nsucceed, but no LDAP password is available, since the user's\nidentity was verified by the external method. The failed\nauthentication was only permitted to fall through to account\ncreation if the user was *absent* from the LDAP directory.\n\nThe result, since Zulip Server 2.1.0, was a silent redirect back to\nthe login page -- a loop with no account created, no user-facing\nerror, nothing in the error logs beyond a DEBUG-level \"Rejecting\nempty password\" line, and a stray PreregistrationUser row\naccumulating for each attempt.\n\nAllow account creation to proceed whenever the user's identity was\nalready verified by an external authentication method, as scenario 2\nof the comment added in the fix for CVE-2023-28623 already promised.\nThat CVE's protection is unaffected: signups whose only verification\nis an email confirmation link still require LDAP authentication when\nEmailAuthBackend is disabled. This does additionally allow an\nexternally-verified user whose email matches LDAP_APPEND_DOMAIN but\nwho is missing from the LDAP directory to sign up, matching the\nbehavior of servers that enable the external method without the LDAP\nbackend.", |
| 6 | + "a23b077b79cae11757fb97f8d4e174af153c7104": "CVE-2023-28623: Prevent unauthorized signup with ldap + external auth.\n\nSince 74dd21c8fa13 in Zulip Server 2.1.0, if:\n- ZulipLDAPAuthBackend and an external authentication backend (any aside\n of ZulipLDAPAuthBackend and EmailAuthBackend) are the only ones\n enabled in AUTHENTICATION_BACKENDS in /etc/zulip/settings.py\n- The organization permissions don't require invitations to join\n\n...then an attacker can create a new account in the organization with\nan arbitrary email address in their control that's not in the\norganization's LDAP directory.\n\nThe impact is limited to installations which have the specific\ncombination of authentication backends described above, in addition to\nhaving the \"Invitations are required for joining this organization\norganization\" permission disabled.", |
| 7 | + "3df1b4dd7c210c21deb6f829df19412b74573f8d": "CVE-2023-28623: Prevent unauthorized signup with ldap + external auth.\n\nSince 74dd21c8fa13 in Zulip Server 2.1.0, if:\n- ZulipLDAPAuthBackend and an external authentication backend (any aside\n of ZulipLDAPAuthBackend and EmailAuthBackend) are the only ones\n enabled in AUTHENTICATION_BACKENDS in /etc/zulip/settings.py\n- The organization permissions don't require invitations to join\n\n...then an attacker can create a new account in the organization with\nan arbitrary email address in their control that's not in the\norganization's LDAP directory.\n\nThe impact is limited to installations which have the specific\ncombination of authentication backends described above, in addition to\nhaving the \"Invitations are required for joining this organization\norganization\" permission disabled." |
| 8 | + }, |
4 | 9 | "CVE-2026-40300": { |
5 | 10 | "c7ddd7884aced3b1ee9017fa4f11d0c69048bf9b": "CVE-2026-40300: Use allowlist for edit history moves-only visibility.\n\nThe previous denylist approach removed prev_content,\nprev_rendered_content, and content_html_diff from move events, but\nleft content and rendered_content visible. This leaked the message\nbody through every moves-only history entry. The code also mutated\ninput dicts in place.\n\nSwitch to an allowlist that copies only move-related properties\n(timestamp, user_id, topic, prev_topic, stream, prev_stream) into a\nfresh dict. Each field is copied only if present, since this\nfunction is called both with FormattedEditHistoryEvent values from\nthe edit-history endpoint and with raw EditHistoryEvent values from\nthe message-fetch path, where topic and stream only appear in events\nthat actually changed them.\n\nCo-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>" |
6 | 11 | }, |
|
71 | 76 | "4c4caa7be46aaed9c6c355307ab38ae99cf1c6d9": "CVE-2023-32677: Check permission to subscribe other users in invites.\n\nThis commit updates the API to check the permission to subscribe other\nusers while inviting. The API will error if the user passes the\n\"stream_ids\" parameter (even when it contains only default streams)\nand the calling user does not having permission to subscribe others to\nstreams.\n\nFor users who do not have permission to subscribe others, the\ninvitee will be subscribed to default streams at the time of\naccepting the invite.\n\nThere is no change for multiuse invites, since only admins are allowed\nto send them, and admins always have the permission to subscribe\nothers to streams.", |
72 | 77 | "7c2693a2c64904d1d0af8503b57763943648cbe5": "CVE-2023-32677: Check permission to subscribe other users in invites.\n\nThis commit updates the API to check the permission to subscribe other\nusers while inviting. The API will error if the user passes the\n\"stream_ids\" parameter (even when it contains only default streams)\nand the calling user does not having permission to subscribe others to\nstreams.\n\nFor users who do not have permission to subscribe others, the\ninvitee will be subscribed to default streams at the time of\naccepting the invite.\n\nThere is no change for multiuse invites, since only admins are allowed\nto send them, and admins always have the permission to subscribe\nothers to streams." |
73 | 78 | }, |
74 | | - "CVE-2023-28623": { |
75 | | - "a23b077b79cae11757fb97f8d4e174af153c7104": "CVE-2023-28623: Prevent unauthorized signup with ldap + external auth.\n\nSince 74dd21c8fa13 in Zulip Server 2.1.0, if:\n- ZulipLDAPAuthBackend and an external authentication backend (any aside\n of ZulipLDAPAuthBackend and EmailAuthBackend) are the only ones\n enabled in AUTHENTICATION_BACKENDS in /etc/zulip/settings.py\n- The organization permissions don't require invitations to join\n\n...then an attacker can create a new account in the organization with\nan arbitrary email address in their control that's not in the\norganization's LDAP directory.\n\nThe impact is limited to installations which have the specific\ncombination of authentication backends described above, in addition to\nhaving the \"Invitations are required for joining this organization\norganization\" permission disabled.", |
76 | | - "3df1b4dd7c210c21deb6f829df19412b74573f8d": "CVE-2023-28623: Prevent unauthorized signup with ldap + external auth.\n\nSince 74dd21c8fa13 in Zulip Server 2.1.0, if:\n- ZulipLDAPAuthBackend and an external authentication backend (any aside\n of ZulipLDAPAuthBackend and EmailAuthBackend) are the only ones\n enabled in AUTHENTICATION_BACKENDS in /etc/zulip/settings.py\n- The organization permissions don't require invitations to join\n\n...then an attacker can create a new account in the organization with\nan arbitrary email address in their control that's not in the\norganization's LDAP directory.\n\nThe impact is limited to installations which have the specific\ncombination of authentication backends described above, in addition to\nhaving the \"Invitations are required for joining this organization\norganization\" permission disabled." |
77 | | - }, |
78 | 79 | "CVE-2023-22735": { |
79 | 80 | "2f6c5a883e106aa82a570d3d1f243993284b70f3": "CVE-2023-22735: Provide the Content-Disposition header from S3.\n\nThe Content-Type of user-provided uploads was provided by the browser\nat initial upload time, and stored in S3; however, 04cf68b45ebb\nswitched to determining the Content-Disposition merely from the\nfilename. This makes uploads vulnerable to a stored XSS, wherein a\nfile uploaded with a content-type of `text/html` and an extension of\n`.png` would be served to browsers as `Content-Disposition: inline`,\nwhich is unsafe.\n\nThe `Content-Security-Policy` headers in the previous commit mitigate\nthis, but only for browsers which support them.\n\nRevert parts of 04cf68b45ebb, specifically by allowing S3 to provide\nthe Content-Disposition header, and using the\n`ResponseContentDisposition` argument when necessary to override it to\n`attachment`. Because we expect S3 responses to vary based on this\nargument, we include it in the cache key; since the query parameter\nhas dashes in it, we can't use use the helper `$arg_` variables, and\nmust parse it from the query parameters manually.\n\nAdding the disposition may decrease the cache hit rate somewhat, but\ndownloads are infrequent enough that it is unlikely to have a\nnoticeable effect. We take care to not adjust the cache key for\nrequests which do not specify the disposition.", |
80 | 81 | "36e97f8121a19a7955e666d24a80ea2cf3d0b75a": "CVE-2023-22735: Set a Content-Security-Policy header on proxied S3 data.\n\nThis was missed in 04cf68b45ebb5c03247a0d6453e35ffc175d55da; as this\ncontent is fundamentally untrusted, it must be served with\n`Content-Security-Policy` headers in order to be safe. These headers\nwere not provided previously for S3 content because it was served from\nthe S3 domain.\n\nThis mitigates content served from Zulip which could be a stored XSS,\nbut only in browsers which support Content-Security-Policy headers;\nsee subsequent commit for the complete solution." |
|
0 commit comments