When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously was used to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent `POST` request. The problem exists in the logic for a reused handle when it is changed from a PUT to a POST.
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
The product exposes a resource to the wrong control sphere, providing unintended actors with inappropriate access to the resource.
Link | Tags |
---|---|
https://hackerone.com/reports/1704017 | third party advisory issue tracking exploit |
https://security.gentoo.org/glsa/202212-01 | third party advisory vendor advisory |
https://security.netapp.com/advisory/ntap-20230110-0006/ | third party advisory |
https://support.apple.com/kb/HT213604 | third party advisory |
https://support.apple.com/kb/HT213605 | third party advisory |
http://seclists.org/fulldisclosure/2023/Jan/20 | third party advisory mailing list |
http://seclists.org/fulldisclosure/2023/Jan/19 | third party advisory mailing list |
https://www.debian.org/security/2023/dsa-5330 | third party advisory vendor advisory |
https://lists.debian.org/debian-lts-announce/2023/01/msg00028.html | third party advisory mailing list |
https://security.netapp.com/advisory/ntap-20230208-0002/ | third party advisory |
http://www.openwall.com/lists/oss-security/2023/05/17/4 | mailing list |