If the functionality is not part of the library's API, you shouldn't use it. There's no guarantee it will still be available in future versions, and that it won't change. So using reflection to access the internals is a strategy of last resort.
It is often sensible to fork the library and add this functionality yourself. You can then offer a pull request to the upstream project, so that your changes may be part of a future mainstream release. This strategy is preferable because your change will be supported by the upstream project. But this only works if your change fits into the vision of the project, e.g. no drastic expansion of scope. Just changing a method from private to public is likely not an acceptable change. That's a hack. Instead, evaluate how the library should be designed in order to address your use case.
If the upstream project will not accept your suggestion, you can still maintain your fork. However, this makes it difficult to keep up to date with updates. This is especially problematic for security updates. Over time, merging upstream with your changes will become more and more difficult as they diverge. Please consider whether you can commit to the maintenance of this fork, and therefore carry this risk.
For changes that are only useful to you, provide that functionality as a completely separate class or library. If the original library is licensed appropriately, you can reuse relevant parts of the source code. Simply copying a whole class and changing some details is not likely to be helpful. Instead, view this source code as a starting point for your own design.