Reliability and security of our software products is a top priority. Since 2002 the gSOAP software is subjected to rigorous testing as part of quality assurance practices. We privately use an extensive collection of unit and regression tests. Our source code is continuously analyzed by the most aggressive top-rated static analysis tools, including Fortify, Coverity and Valgrind (the gSOAP engine also includes a built-in leak checker enabled in DEBUG mode). And first and foremost, the gSOAP source code is downloaded a million times by satisfied developers working at small to large companies world-wide. We listen to you to improve our software and add features, so let us know if you need assistance by [contacting us.](contact.html) 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]( 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 issues are fixed within a week of notification to Genivia with a software upgrade of the open-source and commercial software versions. In addition, all commercial gSOAP software release versions 2.7 and 2.8 are patched and updated to resolve critical issues. To stay informed on important updates, [subscribe]( 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]( and [SourceForge gSOAP support tracker.]( We monitor these trackers and you will receive status updates as the issues are addressed over time. 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. 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**. In fact, stand-alone gSOAP SOAP/XML and JSON Web services simply ignore the URL path part. Furthermore, the GET plugin can be used to load and send a file, **but only with manual code written by a developer**. 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 and 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 vulnerable to denial of service because of a long TCP bind queue and long socket timeouts. Our documentation specifically states 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](images/go-up.png) To top](advisory.html)