diff --git a/nghttp2-1.54.0.tar.xz b/nghttp2-1.54.0.tar.xz
deleted file mode 100644
index fef9c64..0000000
--- a/nghttp2-1.54.0.tar.xz
+++ /dev/null
@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:20533c9354fbb6aa689b6aa0ddb77f91da1d242587444502832e1864308152df
-size 1541460
diff --git a/nghttp2-1.55.1.tar.xz b/nghttp2-1.55.1.tar.xz
new file mode 100644
index 0000000..4887e76
--- /dev/null
+++ b/nghttp2-1.55.1.tar.xz
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:19490b7c8c2ded1cf7c3e3a54ef4304e3a7876ae2d950d60a81d0dc6053be419
+size 1541884
diff --git a/nghttp2.changes b/nghttp2.changes
index f49955c..953f505 100644
--- a/nghttp2.changes
+++ b/nghttp2.changes
@@ -1,3 +1,49 @@
+-------------------------------------------------------------------
+Sat Jul 15 15:11:52 UTC 2023 - Dirk Müller <dmueller@suse.com>
+
+- update to 1.55.1:
+  * Fix memory leak
+    This commit fixes memory leak that happens when
+    PUSH_PROMISE or HEADERS frame cannot be sent, and
+    nghttp2_on_stream_close_callback fails with a fatal error.
+    For example, if GOAWAY frame has been received, a 
+    HEADERS frame that opens new stream cannot be sent.
+    This issue has already been made public via CVE-2023-35945
+    by envoyproxy/envoy project.  During embargo period, the
+    patch to fix this bug was accidentally submitted to
+    nghttp2/nghttp2 repository [2]. And they decided to
+    disclose CVE early.  I was notified just 1.5 hours
+    before disclosure.  I had no time to respond.
+    PoC described in [1] is quite simple, but I think it is
+    not enough to trigger this bug.  While it is true that
+    receiving GOAWAY prevents a client from opening new stream,
+    and nghttp2 enters error handling branch, in order to cause
+    the memory leak, nghttp2_session_close_stream function
+    must return a fatal error.
+    NGHTTP2_ERR_NOMEM, as its name suggests, indicates out of
+    memory.  It is unlikely that a process gets short of
+    memory with this simple PoC scenario unless application
+    does something memory heavy processing.
+  * NGHTTP2_ERR_CALLBACK_FAILURE is returned from application
+    defined callback function (nghttp2_on_stream_close_callback, in
+    this case), which indicates something fatal happened inside a
+    callback, and a connection must be closed immediately without
+    any further action.  As nghttp2_on_stream_close_error_callback
+    documentation says, any error code other than 0 or
+    NGHTTP2_ERR_CALLBACK_FAILURE is treated as fatal
+    error code.  More specifically, it is treated as if
+    NGHTTP2_ERR_CALLBACK_FAILURE is returned.  I guess that
+    envoy returns
+    NGHTTP2_ERR_CALLBACK_FAILURE or other error code which is
+    translated into NGHTTP2_ERR_CALLBACK_FAILURE.
+    https://github.com/envoyproxy/envoy/security/advisories/GHSA-
+    jfxv-29pc-x22r
+
+-------------------------------------------------------------------
+Sat Jul 15 15:11:42 UTC 2023 - Dirk Müller <dmueller@suse.com>
+
+- update to 1.55.1: 
+
 -------------------------------------------------------------------
 Tue Jun 20 20:48:11 UTC 2023 - Dirk Müller <dmueller@suse.com>
 
diff --git a/nghttp2.spec b/nghttp2.spec
index 8243756..24ab0a6 100644
--- a/nghttp2.spec
+++ b/nghttp2.spec
@@ -22,7 +22,7 @@
 %global sover_asio 1
 %global flavor @BUILD_FLAVOR@%{nil}
 Name:           nghttp2
-Version:        1.54.0
+Version:        1.55.1
 Release:        0
 Summary:        Implementation of Hypertext Transfer Protocol version 2 in C
 License:        MIT