<
The bugs and minor issues ratio per line of code is very low and far below the industry average: **only 0.047% bugs or minor issues per line of code were found in the released gSOAP products since 2002.** That is 0.47 bugs and minor issues per 1,000 lines of the [829,000 lines](https://www.openhub.net/p/gsoap/analyses/latest/languages_summary) of gSOAP code. Excluding all examples and other non-essential code, this is still **less than 0.15% bugs or minor issues per line of code.** We even included all **minor issues** in this ratio, such as updates to comply with protocol standards updates and fixes for C/C++ compilation issues to improve platform portability.
Because all bug fixes are already listed in the changelog and very few vulnerabilities have been found since the product launch in 2002, we no longer duplicate some of these specific cases here. All software update reports can be found in the official [changelog.](changelog.html)
All vulnerabilities, bugs and other issues reported to Genivia were quickly fixed within a week of notification with a software upgrade of the open source and commercial software versions. No reported vulnerabilities remain in any of the commercial gSOAP software release versions 2.7.x to 2.8.x available for download from the official [download page.](downloads.html)
To stay informed on important updates, [subscribe](https://eepurl.com/cW6GT1) to receive notifications from Genivia.
In addition to offering free advice to developers in [tutorials](tutorials.html), [examples](examples/index.html) and [documentation](docs.html), Genivia also offers technical support and expert consulting services. [Contact us](contact.html) to inquire.
Thank you for giving us the opportunity to serve you!
How to request technical support when you have a problem or found a bug
---
If you find an issue that is not already addressed in the [changelog,](changelog.html) then here is what you should do.
### Commercial edition users
You are entitled to our timely expert professional support. Please [submit a ticket](inquire/support.php) or [contact us](contact.html) for more details about technical support services offered by Genivia.
### Open source users
Report bugs or ask for support by visiting the [SourceForge gSOAP bug tracker](http://sourceforge.net/p/gsoap2/bugs/) and [SourceForge gSOAP support tracker.](http://sourceforge.net/p/gsoap2/support-requests/) We monitor these trackers and you will receive status updates as the issues are addressed over time.
Upgrade recommendation when option -c++11 is used to generate C++11 source code
-------------------------------------------------------------------------------
A bug was discovered in command option `-c++11` (or `-c++14` or `-c++17`) of the wsdl2h and soapcpp2 tools versions prior to 2.8.133 when this option is used in combination with soapcpp2 option `-d` to generate DOM `xsd__anyType` "catch all" members of a class. When both of these options are used and a set of additional conditions are met at compile time and at runtime, then the generated code may become unstable before a processing error code is returned to the application. Normally error codes are returned immediately to the application. If your application was built with wsdl2h and/or soapcpp2 with options `-c++11` (or `-c++14` or `-c++17`) and option `-d` (i.e. using `dom.cpp`), then updating to the latest 2.8.133 release is recommended to regenerate source code. Alternatively, wsdl2h/soapcpp2 option `-c++11` can be completely omitted from wsdl2h and soapcpp2 to regenerate standard C++ source code that does not require C++11 to compile. Warnings given by soapcpp2 pertaining the use of C++11 data types when option `-c++11` is omitted can be safely ignored as these warnings are solely informative.
Upgrade recommendation when compression is enabled
--------------------------------------------------
A non-trivial edge case bug in zlib decompression may occur in some gSOAP versions up to and including version 2.8.120 (version 2.8.121 is OK). In the worst case this bug may cause an abort, but otherwise does not incur any side effects and is fully recoverable. This bug is exposed when several other factors are combined that must be present for this bug to cause an abort instead of a graceful soft error. However, because of the potential of an abort, we strongly recommend upgrading to version 2.8.121 or download a recently updated 2.7 or 2.8 version from our updated [download site.](downloads.html#releases)
Note: by default, zlib compression is not supported and enabled (it is generally not required). Zlib compression is enabled when applications developed with gSOAP are compiled with `-DWITH_GZIP` or when linked with libgsoapssl/libgsoapssl++.
gSOAP does not use Apache Log4j
-------------------------------
We received several questions pertaining the recent Apache Log4j vulnerability. The gSOAP software does not use Apache Log4j and does not include Log4j. Apache Log4j is not required to be used with gSOAP and not mentioned anywhere in the gSOAP documentation.
gSOAP Apache module not impacted by CVE-2022-28614
--------------------------------------------------
This CVE specifically states:
*“...may read unintended memory if an attacker can cause the server to reflect very large input using `ap_rwrite()` or `ap_rputs()`"*
The strings passed to the `ap_rwrite()` or `ap_rputs()` functions in the gSOAP Apache module are always small and never larger than 64K, which is the gsoap engine's maximum output buffer size to output data in blocks.
glibc getaddrinfo bug CVE-2023-4527
-----------------------------------
The CVE specifically states:
*"A flaw was found in glibc. When the getaddrinfo function is called with the AF_UNSPEC address family and the system is configured with no-aaaa mode via /etc/resolv.conf, a DNS response via TCP larger than 2048 bytes can potentially disclose stack contents through the function returned address data, and may cause a crash."*
The gSOAP engine calls `getaddrinfo()` with `PF_UNSPEC` when compiled with `WITH_IPV6` to enable IPv6 support. Therefore, it is recommended to upgrade glibc. Note that when gSOAP applications are not compiled with `WITH_IPV6` then `AF_UNSPEC` and `PF_UNSPEC` are never used.
Not gSOAP bugs but related
--------------------------
### False claim of a security risk when gSOAP is used
It was brought to our attention that false claims of security risks are publicly posted online, claiming that trajectory traversals are allowed with HTTP GET (or other HTTP methods) with gSOAP. However, the gSOAP software **does not offer web servers or library functions that use the path part of the HTTP request URL to access and send or load files via trajectory traversals**. In fact, stand-alone gSOAP SOAP/XML and JSON Web services simply ignore the URL path part.
The GET plugin can be used to load and send a file, **but only with manual code written by a developer who is in full control of what is sent with HTTP GET**. Moreover, since 2003 the gSOAP software includes the source code of one example web server to assist developers to use URL path to serve HTTP GET requests, in which **directory traversals are explicitly forbidden**. It states very clearly why:
int http_GET_handler(struct soap *soap)
{
... // note: a small piece of code is located here that deals with compressed HTML requests
/* Use soap->path (from request URL) to determine request: */
if (options[OPTION_v].selected)
fprintf(stderr, "HTTP GET Request '%s' to host '%s' path '%s'\n", soap->endpoint, soap->host, soap->path);
/* we don't like requests to snoop around in dirs, so we must reject request that
have paths with a '/' or a '\'. You must at least check for .. to avoid request
from snooping around in higher dirs!!! */
if (strchr(soap->path + 1, '/') || strchr(soap->path + 1, '\\'))
return 403; /* HTTP forbidden */
Also our [tutorials](tutorials.html) state for many years the following paragraph in "How to make stand-alone services serve HTTP GET requests":
"*This example returns the content of file `service.wsdl` located in the current directory, upon receiving a URL with a `?wsdl` query string. It may be tempting to return files referenced in the `soap->path` string, but **do not use the path to simply return files referenced in the url** without making sure that the directories and files opened do not pose security risks. Strip all `/` from the file names to open, or at least strip `..` to prevent snooping around with `../../` from the directory root.*"
Likewise, the [HTTP GET plugin documentation](doc/guide/html/group__group__io.html#ga0ecdc43a53e494edc4f84e8c135659ba) warns of the same.
It is obviously clear that we made all possible efforts for many years to force developers to understand the security implications of using `soap->path` unconstrained. **If a developer deliberately ignores our documentation, our warnings, and the examples that we made publicly available, then the developer is deliberately implementing a well-known problem with custom code.**
### Not an actual gSOAP bug or vulnerability (Jan 2019)
The makers of a certain type of product implemented an iterative web server, which makes it vulnerable to denial of service CVE-2019-6973 because of a long TCP bind queue and long socket timeouts. **This is not a gsoap software vulnerability, but rather a bad choice made by the vendor to write custom server code before gsoap server code is executed.** Our documentation specifically states for years that multi-threaded servers should be implemented, not iterative which are known to block requests! In fact, since 2003 we offer public recommendations on how to safely implement web servers in the gSOAP [user guide](doc/guide/html/index.html) and in our [tutorials](tutorials.html#How_to_implement_and_deploy_gSOAP_Web_services). For over a decade, the documentation specifically addresses the critical importance of proper socket timeouts and how to safely deploy services as multi-threaded services or with Apache or IIS, as demonstrated by our example web server demo included with the gSOAP software (since 2003). This part of the gSOAP library API and the documentation has not changed on these important matters since 2003 and is field-tested safe when used properly. Developers should follow our documentation, tutorials, and the examples that we make publicly available. When in doubt, contact us for technical support!
[ To top](advisory.html)
]]>